A Couple of Words about Swift

It seems everyone has something to say about Swift, the new language for developing on Apple’s Mac and iOS platforms.

Things like: “Do we really need another programming language?” Or, “Clearly, Swift borrowed feature X from language Y.” Or, “Boy, not including feature Z really cripples Swift.”

Am I any more qualified than the rest of the rabble to comment? No. But I won’t let that stop me.

Swift is an Amazing Achievement

Consider Objective-C, the language in which the Cocoa frameworks are written.  At birth, Objective-C most closely resembled Smalltalk-80 glued to a C compiler.  The syntax for message sends was clearly borrowed from Smalltalk, and the extreme late-binding dynamic behavior was, too.  Over time, Objective-C acquired a little bit of static typing, but it was mostly hints, not guarantees that a compiler could (or should) rely on.  At bottom, every message send went through dynamic dispatch (objc_msgSend).

Objective-C, some joked, combined the type-safety of C with the performance of Smalltalk.

Objective-C was the big loser in the battle for a mainstream language that extended C with object-oriented capabilities.  (C++ won that battle, but it ultimately lost the war to Java.)  Developers knew that Objective-C was an Apple-only ghetto.  But they also knew that the language was not as important as the frameworks.  Remember, all of NextStep Cocoa was written in Objective-C.  So, they put up with the limitations of Objective-C, but something was happening in the world.

After a (Java-induced?) lull, people started paying more attention to programming language alternatives.  C++ templates and Java generics made strict compile-time typing the norm, and programmers began to get used to the idea of having the compiler eliminate a large class of errors.  Compile-time type guarantees also eliminate most run-time checks, yielding performance improvements.  Type inferencing started making inroads into mainstream languages, so that typing declarations didn't require so much typing on the keyboard.  Lambda expressions, first-class functions, and closures also started to make their way into the mainstream from the functional programming community (one area where Objective-C’s blocks were slightly ahead of the game).

The end result of this was, I think, a renewed interest in languages that combine expressiveness with static type safety.  And Apple was at risk of having developers feel a pull away from the Cocoa platform because the Objective-C language was starting to seem behind the times.  Objective-C was not as easy or as fun to use as the newer alternatives.

A New Language, or a New Language?

Apple’s challenge, then, was to introduce a new language that could be used with the existing Cocoa frameworks.  And that, I claim, is exactly why no existing language—no matter how wonderful—could fill the need.

Watch the WWDC 2014 presentations on Integrating Swift with Objective-C and Swift Interoperability in Depth.  Now ask yourself, for every existing candidate language, could it have been adapted to interoperate with Objective-C the way that Swift does?  No.  Could any of them have been tweaked a bit?  Maybe, but at what cost?  Don't forget that many of these languages are relying on an underlying virtual machine with a very specific memory model, and once that is changed, much of the existing implementation cannot be reused.

The constraints of the environment make a new language a better choice, a choice with fewer compromises.

So, yeah, Swift borrows liberally from “Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.”  But it couldn't be any of those, for the most basic of reasons, that requirement of interoperability.

The Good, the Bad, and the Ugly

Are you ready for a subjective laundry list?  Let’s do it!

The Good

• Interactive REPL
• Semicolons?  We don't need no semicolons!
• Unicode
• Immutable and mutable bindings (let and var)
• Type inferencing (can handle recursion in some cases that Scala can’t, it would seem)
• String interpolation
• Array and dictionary literals
• Pattern-matching!
• Closures and first-class functions
• Tuples
• Explicit override
• Optional
• Generics with type constraints
• Protocols
• Extensions
• Arithmetic overflow detection
• Mandatory named parameters (sometimes, you don’t want people to have the option of screwing up)
• Trailing closures, I think. I’m not entirely certain whether this is the right approach; but it does seem useable.

The Bad

• Immutable arrays aren’t.  This is documented behavior, but it may be changed.  (Update: It was changed.)
• Documentation is vague on when/whether dictionary keys are immutable.
• Optional is baked in as a special case.  Don’t expect to use the same syntax for anything you might conjure up yourself.
• Mutable structs that are always passed by value.  How can this be a good idea?
• It seems that genericity and protocols don’t play well together.  I am not sure how well I understand the issue, to be honest, since I have not actually written any Swift code.
• The two-dot/three-dot half-open/closed range syntax is a horrible mistake. (Update: This has been changed, to use ..< and ..., which takes it out of Bad but maybe still leaves it in Ugly.
• Mutable strings
• Generic type constraints are limited, with …
• No explicit covariance/contravariance for generic type parameters
• Not really functional, although the author of that piece is not criticizing, just observing 

The Ugly

• The test-optional-and-bind syntax (if let) is pretty ugly to my eye.  For that matter, so is the pattern matching bind (case let).  My brain does not want to see that let in the middle of a statement.
• I just don’t think switch is the best name for the pattern matching statement.  Pattern matching is so different from what a C switch does.  (Perhaps a case of trying too hard to appear familiar.)
• External names for parameters.  I don’t object strongly to the idea, but the syntax leaves something to be desired.
• String mutability is determined by the kind of binding?  That is weird and confusing.
• C-style for loops are probably unnecessary and may encourage bad style.
• Labeled statements and directed break/continue.  Bleah.
• var parameters.  Why bother?
• inout parameters probably exist only for compatibility with existing code.  A necessary evil, I suppose.
• The keyword in for separating closure header from body grates on me.
• Using static/class modifiers instead of having a single keyword for both cases.

Will It Fly? (sorry)

Contributions on Apple’s developer forums from the Swift team make it clear that Swift is a work in progress.  The Swift creators are interested in feedback and they want to improve the language.

Swift could well achieve one of its open secret goals: to become a teaching language.  (The benefit for Apple is obvious.)  The playground feature is pretty nifty, and I can easily imagine wanting to use it if I were introducing some basic programming concepts.

Would Swift spread beyond the Cocoa domain if the implementation were opened up?  That’s hard to say.  As a language, it does not seem compelling compared to my current favorite, Scala.  The native code compilation has some appeal, but the JVM has a pretty good JIT these days.  The reference counting storage management could be a big deal in certain applications, but the developer overhead in manually managing cycles is hard to justify outside of narrow domains.

For its intended use, however, I would say Swift is a pretty good bet to be successful, and probably make a lot of Cocoa programmers more productive.