Apple announced a new programming language. The inevitable reactions poured in, Apple lovers mostly rejoiced, Apple haters pounded on. Some complained the fact that it was not open source. Here are some thoughts from an observing angle.
A new programming language that launches in 2014 would aim to attract the masses and actually solve problems. If not then nobody would pay attention, regardless of their affinities. There’s been a lot of learning compounded in the software engineering discipline over the years, it would be foolish to sidestep all that and try to bring up something new. These learnings can be found in the existing languages, C#, OCaml, Erlang, Groovy, Scala, Rust, Go, Lua, and many others I might not even be familiar with. So in this context, if you were in any vendor’s shoes, you would need to embrace what’s available and bring it closer to your environment. That’s what Apple has done.
Concurrency and parallelism
It is surprising that Swift does not seem to address concurrency and parallelism the way Erlang for example does, at least not in a visible way so far. It seems they didn’t want to ‘copy’ much from Erlang in fact. One could speculate what Apple’s rationales might be. My immediate thought, when I saw that omission, was that perhaps that would have pushed the enveloppe too far for the current generation of Apple developers. If that were included, a-la-Erlang for example, quite likely the first batch of applications delivered with Swift could be utter disasters and permanently cripple the uptake of the language. Apple would have to first create a solid infrastructure for such parallelism and concurrency constructs. That is the most important reason I can think of for leaving out such paradigms.
Another rationale to consider is the fact that unpredictability doesn’t marry well with user interface behaviour. Parallelism and concurrency are first and foremost systems concerns, more at home with a systems programming language. Apple is heavily focused on the user experience, and much less on system experience (TM). This makes me believe that Apple intentionally decided that Swift would not be a systems programming language. At least not now.
Vindication
Swift appears to be, at least from one vendor’s perspective, a vindication that verbose programming languages don’t make developers productive in this day and age. Also, letting people make simple silly preventable mistakes is not a profitable business. Every time you looked at Objective-C source code, after any amount of time with Clojure, Groovy, Lua, Erlang or OCaml, to name a few, you were left wondering why such status quo persisted. Apple gave their answer today. But they waited a long time for that. Microsoft with C# and particularly F# have long been delivering the goods in that department. Google with GO have been forging ahead and registering tremendous success. Marrying the best aspects of functional programming with sequential and object-oriented programming, deliver the most benefits to users at the moment. With Microsoft, Google, Apple, Mozilla on board, it would be hard to argue that functional programming has become mainstream. The early adopters should rightly feel vindicated, somehow.
Update: A pointer to the reference web site was missing, for those who might not be Apple developers. There is no point in including ‘hello world’ or other trivial sample code here. Swift web site is: https://developer.apple.com/swift/.