This is a first look at Swift, Apple’s new programming language for MacOS and iOS development, which is still in Beta and thus by the time you are reading this, some of the bugs or features discussed here may have changed.
Also, while I have worked with a couple of programming languages over the years, I’m not really into all the latest academic hypes in language design. I’m only interested in one thing: is it fun to code in this language: can I solve problems in an efficient and elegant manner.
Having said this, it may not come as a surprise to you if I say that I never really got warm with Objective-C.
But let’s have a look at Swift now:
The Good
Swift is a modern programming language. It feels fresh and thought-through, and as if its creators were interested in making something useful. That’s not something you will hear me say about many new programming languages.
It also implements concepts like inferred data types, reference counting, generics, extensions and full Unicode support; the runtime knows types like dictionaries and tuples, etc., which is all stuff I would expect from any modern programming language, so I won’t get any deeper into it here.
One concept that particularly catches my interest (in good and in bad) is Optionals. They basically replace nil or null values for objects (which Swift does not know) and C-style typecasting 0 or null values to logical false (frequently used in C but not possible in Swift), all nicely wrapped up in one concept:
var result:Int? = somefunction()
if result {
// do something…
The cool thing is that optionals are not restricted to objects or scalar variables but can be used for any kind of variable.
Another interesting concept is first-class functions and closures. This does not only make it very easy to specify callbacks but allows for some very nice, JavaScript-style function calls in this style:
fetchRessource(uri: someuri,
success: { /* do something */ },
failure: { /* do something else */ }
)
Related to this is the concept of curried functions which Swift now supports (though I must admit that I’m still trying to find a useful example for here)
There is also a lot of syntactic sugar in there, for example Ranges, which are basically automatically generated arrays of numbers, e.g. for iterating over them like this:
for number in 1...9 {
// do something 9 times
}
There are two flavours of ranges, the above is a closed range, i.e. it includes both 1 and 9. There is also a half-open range (e.g. 1..<9) which stops before reaching the final value. This does away with all these -1 you otherwise have to add to your for loops.
Another interesting feature is string inference, that is, strings and other data types can be directly inserted into a string template, similar to C’s printf function, but with a twist:
var points = 11.5 var totalPoints = 24 var str = "You have \(points) of \(totalPoints) points." // str is now “You have 11.5 of 24 points.”
This is a lot more readable than C format strings, but it remains to be seen what new kinds of problems this may cause in the localization process.
No programming language would be complete without a professional IDE and Apple’s Xcode environment looks very promising: There is REPL environment (called a “Playground”) which makes it very easy to try out new ideas and algorithms.
Last but not least: Swift can even be used for writing shell scripts. I’m sure we will see more of these soon.
The Bad
How I see it, things always went bad when Apple tried to think different just for being different’s sake.
This starts with small things, like constants. In most modern programming languages, const is the statement of choice for, well, defining constants. Apple chose let, which admittedly is shorter but a bit too similar to var for comfort.
Unfortunately the different think doesn’t stop there. For error handling, exceptions are usually the weapon of choice, providing a tested and reliable mechanism that allows to create elegant and readable code.
Swift uses conditionals (see above) for error handling, and while this certainly allows for some nice solutions, e.g. if you just want to check if a function call succeeded, there are many situations where exceptions would really make a lot more sense.
What makes these things bad is that they seem to be conceptual decisions that are unlikely to be reversed. We will just have to learn to live with it as it is…
The Ugly
Since quite some time now, a new programming language is expected to come with it’s own, tailored framework library. Microsoft’s C# comes with .Net, Java (the language) comes with, well, Java (the class library), etc. Apple’s Swift inherits Cocoa from Objective-C. Unfortunately, this library is tailor-made for the later and kind of spoils a lot of the elegance and simplicity of Swift.
let nsrange = NSMakeRange(0, 5)
Of course, Cocoa’s own NSRange is not compatible with Swift’s Range object. Bummer.
As things are now, you will find yourself converting back and forth Swift objects to Objective-C objects and back again. More often than not you’ll have to use crouches like
bridgeToObjectiveC() to get the job done.
While Swift successfully removed a lot of the old cryptic C-style syntax, it introduced a lot of new hard-to-understand symbols, most notably related to the new optionals and named parameters. Generously peppering the source code with ?, !, &, # and other cryptic symbols does little to improve readability.
However, at this stage, Swift is still a moving target and Apple still continues to add features, improve the experience and squash the bugs. We will still see if these bugs I mentioned here are really bugs or if they count as “features”.
Speaking of bugs: did I mention that the “Playground” environment keeps crashing? That’s annoying!
The Conclusion
With Swift, Apple has presented the foundations of a fully-fledged, muti-purpose, multi-paradigm programming language. It is a concept so far, not a final product; It still has edges and corners that need some work, and most of all it still needs some time to mature.
If you are already developing for the iOS or MacOS X platforms, it is a good time to start following the developments in this area as Swift is bound to replace Objective C, if not for all purposes then at least for many aspects of development on these platforms.
Until that time, there is still a lot of work waiting for Apple: most of all, the Cocoa framework needs to be adapted to fit the concepts of the new language. And this will still take some time.