After some experiments with Swift, I’ve been spending an increasing amount of time on a new project written completely in Swift. (Project to be revealed in due time.) Faster development, fewer bugs, and more fun — I’m hooked, and I don’t want to go back.
With the open source announcement of Swift delivering everything I wanted and more, there’s no reason to go back. Swift will be my main language for the next decade.
My programming language history
Most of my career has been focused on two large code bases, PowerPoint and SmartGo, and just a few programming languages. These languages have paved my path to Swift.
6502 assembler: After the TI-59 pocket calculator, my first real computer was a KIM-1. With a blistering speed of 1 MHz and a whole 1KB of RAM, that was an amazing machine. I squeezed my first Othello program into that computer, and learned a lot about performance and knowing every bit.
Modula-2: After some Pascal on Apple II, my time at ETH Zürich and UNC Chapel Hill was spent with Modula-2, first on the Lilith and then on the Mac. The original Smart Go Board for Macintosh was written in Modula-2. With the strong influence of Niklaus Wirth, I got drilled in the fundamentals of strong typing and modularity.
C++: When I started at Microsoft in 1991, most of the PowerPoint code was in C, with some Pascal in Mac-specific files (PowerPoint originally started as a Pascal program on the Mac). Over the next several releases, piece by piece, we successfully rewrote the whole program in C++, completely object-oriented. Both speed and memory usage were critical, and we learned how to use a subset of C++ to achieve high performance. (At one time, six of the twenty developers on PowerPoint had a connection to ETH Zürich — the Swiss influence was strong on that team. Still is.)
Once I left Microsoft in 1999 to work on SmartGo, C++ on Windows was the natural choice. C++ worked really well for Go, from fast low-level bitset operations to object-oriented UI code. But Vista pushed me over the edge and back to the Mac.
Objective-C: The Mac version of SmartGo got interrupted when Apple opened the iPhone for development. Keeping the base code in C++, I added the UI for SmartGo on iOS as I learned Objective-C. Seven years later, I’ve written a lot of Objective-C code, but it’s not my language of choice. The lack of type safety, the convenience of nil objects hiding potential errors, the need to avoid dynamic allocations and message passing in tight loops: these all worked against my nature. And having to interface with Go-specific code in C++ kept me from taking advantage of the full power of Objective-C.
Swift: With just a few months of Swift experience, it’s already clear that it gives me the building blocks for writing fast, high-quality software for the game of Go. It has strong typing and performance rivaling C++. It supports operator overloading (useful for bitset operations in Go) and generics (useful for arrays indexed by .Black and .White). Unicode string handling is a godsend for a game that originated in the Far East. Value semantics. Returning tuples. No crazy block syntax. Functional programming. And good riddance to semicolons.
I’m still in the early stages of learning Swift, and I’m already writing code better and faster than with the subset of C++ I had been using for 20 years. Did I mention it’s more fun too? So to me, it’s a clear choice.
I know where I’m going: my apps are transitioning to Swift. I know the first step: a separate Swift project to help me master the language and build up some base modules. After that? It will take me a while, but I will figure it out.
Transitioning a large code base is risky and never easy. I have no illusions that this will be simple. (Moving PowerPoint to C++ was good practice, but also a warning.) The fact that Swift doesn’t interoperate with C++ makes it harder. And it all has to be done while keeping the existing apps healthy and customers happy and dealing with any other curve balls Apple throws my way.
Yes, this will slow down development on my Go apps for the next years. It’s a risk I have to take: I’ve worked on these apps for fifteen years, and plan to work on them for many more. As an indie developer, I need to invest in my apps and in myself.