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.

swiftb is a Vim plugin I made to support open-source Swift (the swift.org version) syntax checking in Syntastic which is itself a Vim plugin. The code is on GitHub.

Behind the scenes it is using swift build — the build option available only in the open-source toolchain so far. The errors are the same that you can find in Xcode, and Syntastic makes them available with line marks and both command window and location list. Though I have an option set which prevents the location list from opening automatically, it can only close if there are no more errors:

let g:syntastic_auto_loc_list = 2

Sadly there is no autocompletion yet. There is decent support via SourceKitten but it’s only working for Xcode projects. I only have Package.swift :)