Jul 7th 2014
Not So Fast, Swift!
Last month at its World Wide Developer Conference, Apple surprised everyone by announcing not an iWatch or new Macs or their fabled Apple Television, but a new programming language dubbed Swift. The reactions, ranging from ecstasy to rage, have been nearly as interesting at Swift itself. Some longtime Apple developers were dismayed at, or even angered by, the possibility that the new language could cheapen their experience in the venerable workhorse, Objective-C. At the same time, many would-be iOS developers, long dissuaded from entering the field by Objective-C, rejoiced at what they hope will be an easier on-ramp for them.
Perhaps the most interesting aspect of the announcement is the way in which Swift seems to be acting as digital inkblot test, in which observers first see what they expect to see. In that way, Swift calls to mind the parable of the blind men grasping different parts of an elephant.
C# developers saw similarities to their language in Swift's generics and object system, and many proclaimed, "Bah, Apple is just ripping off features from C#!" To which Java programmers replied, "Where do you think C# got all its features, eh?!"
Fans of the ML family of languages — F#, OCaml, Scala, and Haskell — took note of Swift's type system and first class functions and promptly declared that Swift properly belongs in their family tree.
Ruby programmers were comforted by the lack of semi-colons and the clean new syntax that dispenses with much of Objective-C's more baroque constructs and conventions.
Python programmers were heartened by Swift's embrace of tuples and list comprehension-like abilities.
Smalltalk aficionados shed a tear at the loss of the brackets and message syntax that Objective-C had borrowed from their language of choice, but they rejoiced upon seeing the interactive Playgrounds in action because it gave them hope that others would finally recognize the benefits of Smalltalk's fully interactive environments.
Rust, Groovy, Pascal — practically any language you name can be found somewhere in some aspect of Swift.
Even Lisp experts, after seeing examples of how Swift's operator overloading and other advanced features can be used to create new idioms and behaviors, they recognized a shadow of their own Lisp macros and aptitude for domain-specific languages (DSLs). Of course, they went on to point out that Swift itself could be implemented as a DSL in Common Lisp.
The truth is that all of these people are going to be disappointed. Not because Swift is poor language in some way, but because by trying to force Swift to be something it is not, they will make it less than it is.
That's partially because Swift is first and foremost a polyglot language. It was developed by engineers with strong experience in compiler and language design who were seeking to elegantly incorporate many of the best practices that have emerged in software development over the past 20 years.
Even more than its Borg-like assimilation of distinctiveness, Swift is somewhat unique (or at least rare) in the experience of most modern developers, and as such, it should come as no surprise that so many people failed to recognize its primary advantage. What makes Swift so unusual is the fact that it is one of very few languages, and probably the first in quite a long time, that was designed and introduced for a specific purpose — in this case, development for iOS and the Mac. Most other languages we're familiar with were conceived of primarily as general-purpose languages and only gained widespread acceptance when they found their niche, or "killer app." There are exceptions, of course, such as Java and C++, but the pattern is still fairly common.
Even Objective-C had been around for over 20 years, for nearly a decade as the primary language of Mac development, before iOS development catapulted it into the top 5 of the TIOBE index, a popular metric of interest in computer languages. It is current ranked #3 behind C and Java.
That is the niche that Swift was tailor-made to fill, not only for current Apple developers but for the thousands who will be attracted by Swift's relative approachability compared to Objective-C. When it is added to the TIOBE index, it will likely premiere in the top 20, probably in the mid teens, and will probably climb over the next few years to trade places with Objective-C. That is meteoric growth for any language and will be attributable almost entirely due to its association with iOS.
Swift's probably growth and popularity, though, also give cause for a cautionary note, especially to those who hope the removal of the "Objective-C Barrier" will finally allow them to make iOS apps: the language is not the hard part. The truth is that for all its fearsome reputation, Objective-C was never all that big and bad. Cocoa, the collection of libraries and frameworks used for iOS and Mac development, on the other hand, is far, far bigger than Objective-C. Thankfully, it is big, but not bad. Cocoa is a strong, elegant, coherent framework, which makes it easier to learn than many others, but it still rewards idiomatic use and punishes non-idiomatic use.
Also, Cocoa itself is still written in Objective-C, which means that understanding Obj-C and its conventions will remain important for the foreseeable future, not to mention that its users can benefit from 30 years of collective experience and examples. Knowledge of Cocoa will remain critical for iOS development, regardless of the language you use.
And, finally, the most difficult part of programming will, as always, remain the mindset — the training and discipline of thought that allows you to logically examine a problem, conceive of a solution, break the solution down into component parts, then methodically assemble and deploy it. That skill is not dependent on any specific language.
Swift is a promising language, but it is not a silver bullet. It will be worth learning, and possibly quite enjoyable to use, but it won't do the hard parts for you. And it will probably open the door to thousands and thousands of new programmers who will find that removing the first barrier only makes the next one easier to perceive.
But then that's what software development is really all about progressing from one problem or puzzle to the next until you've solved enough of them that your program works. And that's the pursuit that makes it so deeply rewarding and engaging!