Why not write about some of the books I read in January? Honestly, thinking about writing a post about some of my reading prompted me to read more, so it’s a good thing and I’m planning to keep up the habit.

“Functional Swift” by Chris Eidhof, Florian Kugler and Wouter Swiersta of objc.io

I believe it was called “Functional programming in Swift” recently, but when the book was updated in December 2015 for Swift 2.1 (which I read) it got renamed as well, and for the better.

This one read a lot like the Apple’s official Swift book for me: clear, concise, to the point and at the same time introductory. The book consists of several sections exploring different topics e. g. writing a wrapper for Core Image or implementing a test suite which generates tests automatically, all of them revolving around the functional approach to solving problems.

I would say that the authors succeed in demonstrating that writing in a functional way is at least as safe and rewarding, if not superior, than a more imperative approach. A typical Swift programmer comes either from the Objective-C or, possibly, the frontend JavaScript background, both of the languages loosely-typed as in not encouraging being strict with your types. This book gently presents a different approach and prompts for further reading (at least I was sufficiently interested to read further).

If you’re interested in the actual functional programming, reading “Learn you a Haskell” would be more beneficial, but if you’re curious how to think differently while writing in Swift or learn some new approaches to common problems, it’s a great introductory book that you can later supplement with more reading on the topic, having the primaries down.

“Turning Pro” by Steven Pressfield

This is a small but intense book intended for everyone who is (or should be) hard at work. I read it last time three years ago, worked a lot since then, and this time it stood out even brighter than before. It’s a great reminder why you would jump out of bed each morning and work hard. A motivational book, so to say, but not in a happy way — a sobering one: the work is hard and it’s you who has to do it, no exceptions.

Here’s my slightly longer review on Goodreads if you’re interested.

The final two books are (surprise!) about financial markets and specifically, high-frequency trading. Why read them over crunchy programming books? December saw the launch of Stockfighter, a game where you basically write a trading bot to try and game the simulated financial market. Yes, this is supposed to be someone’s idea of having a good time, and incidentally I had a good time designing and (partly) writing my own library for it. Anyway, on to the books.

“Flash Boys” by Michael Lewis

Lewis is a good writer and writes a good story, but when it comes to the technical details… not so much. Some glaring holes right there, and far more than once I was close to making a facepalm.

Still, it’s probably the best book to start with on this topic as it paints the picture in large strokes and gives you a good idea of the emotions behind what people were doing. You can read any number of technical books on the subject, there are many, but first you have to dive in and look around, and this is a really good introduction that starts slow and holds you by the hand all the way in.

Yes, some claims are outrageous and plain wrong, but it’s entertaining and Lewis gradually explains most of the buzzwords you’re likely to encounter in other books about the subject.

Don’t confuse it with “Flash Boys: Not So Fast” by Peter Kovac which is sort of a bashing reply to Lewis. Kovac too makes quite a lot of mistakes, judging by the reviews, so I haven’t read it yet.

“Dark Pools” by Scott Patterson

This is another “introductory”, or rather, non-technical book, which looks at the same process described in Lewis’ “Flash Boys”, but from a different angle. Where Lewis mostly follows the story of a banker playing catch-up to high-frequency trading firms, Patterson describes the lives of several prominent people who directly influenced the rise of HFT from the inside. Small shops which eventually grew to enormous size and changed the market altogether.

Arguably, “Dark Pools” is far more technical of the two and I really enjoyed reading it. It’s more technical, but it’s still a story, so it’s perfectly readable and just as entertaining: Patterson goes into a lot of detail on how the markets worked since the early 90s up to the current moment. It also turned out to be more applicable to Stockfighter: quite a few of the actual techniques he describes used by high-frequency traders I can see used in the game verbatim.

Reading about HFT is surely nice, but I decided that I should stop reading and beat a few levels of the game first :)

After reading “Profiling your Swift compilation times” I decided to try it for our project, as it’s about 80% Swift and a couple of Objective-C frameworks. Frankly, dry compile time (after cleaning) is just really bad, pushing 3 minutes. Most of the time compilation is incremental and takes much less time, but the project has to be cleaned several times a day anyway, and the compile times add up.

If the linked post ever goes away, you can profile your project simply by adding the following to your Other Swift Flags in Build Settings for the intended target:

-Xfrontend -debug-time-function-bodies

After that you do the following to get the output file culprits.txt with sorted function compile times:

xcodebuild -workspace Project.xcworkspace -scheme Project clean build | grep [1-9].[0-9]ms | sort -nr > culprits.txt

Here’s an edited excerpt from our project before I started optimizing:

1172.0ms Views/BeaconMeasurementDataTableViewCell.swift:17:10	func configure(beacon: FilteredBeaconData)
1053.3ms Controllers/ClientViewController.swift:855:20	@IBAction @objc func canvasViewTapped(sender: UITapGestureRecognizer)
994.2ms  Helpers/CLLocationDistance.swift:35:17	public func region() -> String?
978.2ms  Helpers/CLLocationDistance.swift:35:17	public func region() -> String?
928.3ms  Controllers/ClientViewController.swift:855:20	@IBAction @objc func canvasViewTapped(sender: UITapGestureRecognizer)
782.2ms  Helpers/CGRectSquare.swift:24:10	func canBeInsetBy(x: CGFloat, y: CGFloat) -> Bool

As you can see, the worst function takes just over a second, and some functions get repeated, so you can edit them once for multiplied benefit. In total, there were about 70 lines with functions taking longer than 100 ms to compile. Here’s the before:

$ time xcodebuild -workspace Project.xcworkspace -scheme Project clean build

real    15m41.535s
user    24m43.824s
sys     2m59.478s

I decided to not spend much time on this as we had a different situation than the linked post’s author and were not likely to get much improvement. So I edited about 10 worst functions (and found a couple of missed bugs in the process, which is an added benefit). Then I ran the test again:

real    13m7.661s
user    22m24.623s
sys     2m46.180s

Not much, but that is still a measurable difference: 16.3% for real, 9.4% for user and 7.4% for sys, so about a 10% improvement in total. Not bad for an hour and a half of work.

I also tried comparing the difference in compile time from Xcode when running the app on the simulator, but couldn’t come to a definite conclusion: even after cleaning, Xcode compile times vary a lot and the total time stayed around the same 3 minutes. Of course, it’s much faster when the libraries and some modules are already cached, usually the build takes no more than 10-15 seconds.

I encourage you to test this for your Swift project if you’re disappointed with compile times, it may well be a quick and big win.

Some fascinating reading this week!

First, the New York Times asking “Why are the corporations hoarding trillions?” where they claim Apple, Google and other giants don’t spend or convert their cash, as if expecting something just beyond the horizon. Something that would need an insane amount of money.

Second, Ben Goertzel with “Superintellingence: fears, promises and potentians”, a through and in-depth review and criticism of current literature by Bostrom, Yudkowsky and others.

This struck me as amusing:

As Peter Norvig of Google has noted (personal communication), quite suddenly we’ve gone from outrage at the perceived failure of AI research, to outrage at the perceived possible success of AGI (Artificial General Intelligence) research!

For the last decade, AI research and theory is booming, and it’s very hard to ignore the fact that every other app or service now has some form of machine learning or AI-like capabilities, the most common example being Siri on iOS. There are many more examples, like Google Now or various personal assistants like AlfaSense, X.ai or even something as simple as a blog layout system.

Very excited to see the progress.