{"id":2865,"date":"2014-06-22T14:54:14","date_gmt":"2014-06-22T17:54:14","guid":{"rendered":"http:\/\/brockerhoff.net\/blog\/?p=2865"},"modified":"2014-06-22T20:51:16","modified_gmt":"2014-06-22T23:51:16","slug":"swift-first-impressions","status":"publish","type":"post","link":"https:\/\/brockerhoff.net\/blog\/2014\/06\/22\/swift-first-impressions\/","title":{"rendered":"Swift: First Impressions"},"content":{"rendered":"

Over\u00a0two weeks ago, Apple at WWDC<\/a> announced something entirely unexpected: thousands of new APIs and a brand-new programming language, Swift. No hardware, of course; it’s a developers<\/em> conference, remember?<\/p>\n

Reactions varied all over the spectrum. Non-developers (especially \u201cindustry analysts\u201d) mostly had no idea what it meant<\/a>: they said Apple had announced \u201cnothing<\/a>\u201d. Almost all\u00a0developers, however, were ecstatic \u2014 \u201cthe most significant event Apple ever staged<\/a>“. Regarding Swift, this initial enthusiasm diverged as soon as people read the (relatively sparse) documentation and actually began to play around with the language \u2014\u00a0a very early beta version was available for download soon after the announcement. Hilarity, chaos and pandemonium<\/a> ensued;\u00a0tension, apprehension and dissension<\/a> had begun.<\/p>\n

As usual, almost everybody tried to project<\/a> their grievances, expectations and experiences onto the new language. The open-source advocates griped that no source was available. The cross-platform advocates complained that there was no version running\/compiling for Android (as if Apple would have any interest in promoting that!). The Objective-C programmers unsuccessfully tried to translate their code into Swift and complained that there was only limited dynamic dispatching and introspection. The C programmers complained that there were no preprocessor macros and that Swift seemed to be \u201cObjective-C without the C\u201d. The Haskell\/Erlang\/Scala programmers complained that many functional programming facilities were missing, and that the language was \u201ctoo mutable\u201d. The Java programmers\u00a0complained that the language was \u201ctoo C++-like\u201d, but resented the lack of exceptions. The C++ programmers also resented the lack of exceptions and wanted std::somethings. The Type Theorists complained that generics were \u201cnot generic enough\u201d. JavaScript programmers… well, you get the idea. Almost everybody complained about Array mutability semantics, about missing semicolons and the parsing of whitespace, and (of course) said that the syntax \u201clooked weird\u201d. Serious fights erupted on Twitter, disagreeing on whether Swift was a \u201cmodern\u201d language and what Apple’s intentions were.<\/p>\n

And, as always happens, many people said, in effect, \u201cOMG Apple you’re soo stooopid WTF fix this now!\u201d. This is the usual symptom of looking at the surface and not understanding what might be happening underneath.<\/p>\n

Voluminous disclaimer and sidenote with historical digressions:<\/p>\n

Many of the complaints in the paragraphs above are condensations of what I understood people to be saying and none are meant to be actual live quotes \u2014 which is why I didn’t link to any specific instance. I’m not interested in discussing most of these personally right now, thank you.<\/em><\/p>\n

I’ve been programming since 1969, \u00a0in C since 1984, in Objective-C since 2000. I wrote only\u00a0<\/em>one<\/a> application in C++ back in the Classic days \u2014 it was pretty much mandatory in the CodeWarrior\/PowerPlant days. I did my CS degree in the early\u00a01970’s, when \u201cmodern\u201d language still meant ALGOL 68<\/a>\u00a0– see the mind-boogling\u00a0official reference<\/a> (<\/em>large PDF).<\/em><\/p>\n

When BYTE Magazine<\/a>‘s special Smalltalk issue<\/a> came out in 1981, I was very interested, but couldn’t come to grips with the weird syntax. I bought\u00a0Adele Goldberg<\/a>‘s classic books about Smalltalk \u2014\u00a0the blue book<\/a>\u00a0(<\/em>large PDF),\u00a0the orange book<\/a>\u00a0(<\/em><\/em>large PDF)<\/em>\u00a0and the green book<\/a> (<\/em>large PDF) \u2014 and periodically tried to understand them; very difficult without access to a working compiler! In the late 80’s I put these aside (and, unfortunately, lost them in a move). After Apple acquired NeXT in 1996, I became aware of Objective-C’s roots in Smalltalk, but didn’t give it much thought.<\/em><\/p>\n

Around 2000, restarting my work as an indie developer, I started programming<\/a> in Objective-C and Cocoa. As an experienced C programmer I had little difficulty with Objective-C, and quickly got used to\u00a0the nested [[ ]]s. I never wrote a full Carbon app as such. I also never managed to acquire a working Smalltalk compiler, even after a few became available on the Mac. However, a couple of years ago, I found the Smalltalk books in PDF format (as linked above) and was astounded: the formerly opaque things about methods, messages, dynamic dispatching, objects and so forth \u2014 suddenly all was clear and obvious! That’s the advantage of using-while-learning, at least for me.<\/em><\/p>\n

Unlike many colleagues I never hesitated to go beyond Cocoa, always\u00a0using CoreFoundation, BSD\/Darwin and a variety of interfaces according to necessity, and once manual memory management became ingrained, tossing objects and buffers back and forth between the various APIs. Except for short utilities for my own use, I haven’t adopted <\/em>ARC<\/a> yet \u2014 I found too many edge cases for my established programming habits.<\/em><\/p>\n

\u00a0So, back to Swift. It really appears to be\u00a0a very pragmatic language. If you look at the generated library header (in Xcode, command-doubleclick on any Swift type to see it), nearly all operators and types are defined there, in often surprising detail. In other words, few language features are hard-wired into the parser\/compiler – the Swift library\/runtime and the pre-LLVM optimizer are, instead, responsible for the language and its implementation details, and therefore more easily twiddled\u00a0if necessary.<\/p>\n

This is, of course, very convenient for Apple: a\u00a0small team could tinker around with all aspects of Swift while leveraging most of the existing LLVM infrastructure<\/a> and keeping up with the latest changes in iOS and OS X. Indeed, in retrospect, it appears that Swift was even driving many\u00a0of those changes!<\/p>\n

Let’s look at a brief timeline to explain what I mean:<\/p>\n