7 June 2014

As I taught myself Objective-C, each new detail I learned struck me as magnificently clever and elegant — even as I was struggling with (or drowning under) its memory management concepts, I understood the rationale behind them. Now Swift spits on all of that heritage and it fails to convince me that it has reasons beyond the personal taste of its designers. Where Objective-C was governed by pragmatism in the face of technical constraints, many of Swift’s syntax choices strike me as simply motivated by the urge to be cute and fashionable. I’m not talking about fundamental concepts here (except for one), but the basic syntax — Swift tries to cram Cocoa compatibility into the silhouette of currently popular functional languages instead of honoring the C and Obj-C legacy, for no other reason than it wants to.

We’re supposed to be impressed that the language was entirely designed by a tiny secret group (and even started out as a single person’s project), but isn’t it actually terrifying? As pointed out in this week’s Debug podcast, there is no bigger, more qualified community in the world of expert Objective-C / Cocoa engineers than the whole of Apple. Why on earth would you design the fundamentals of a new language (I know they’re reserving the right to change details, but you can hardly expect dramatic changes to the syntax) and announce it publicly without asking for that community’s input first? There is absolutely no advantage to secrecy for secrecy’s sake when it comes to an undertaking of this magnitude.

I’ll spare you the list of every little detail that annoys me (why “in”? what the fuck are closure parameters doing inside the braces? and so on) and jump back to the one profound implementation change I have a beef with: the disappearance of nil messaging (by default). Cocoa, in itself, was pretty much structured around the fact that you could link a long chain of method calls and the whole thing would harmlessly revert to “nil” if any individual step failed — and it was lovely. Now we have to wrap everything in question and exclamation marks because… it allowed people to make mistakes? Well, that’s ironic considering how illegible Swift will be when it falls into the hands of developers too clever for their own sake.

Swift was announced as “Objective-C without the C” and I’ll never agree with that premise. C works, C is legible, C is consitent. Pretty much everything Swift brings to the table could have been integrated into a descendent of Obj-C — the most important additions, the ones that will actually make our daily life simpler as app developers, were already available in C# fifteen years ago. Speaking of which, I’d have happily taken proper exception support over all those new compiler-enforced “safety features.”