Swift

Yesterday, Apple announced a new language, Swift. Officially, it doesn’t replace ObjC or ObjC++, the current languages. In practices, of course, we’ll see.

I’m about half-way through the readable part of the book. Swift is very much a member of the C family of languages. Some observations from Day One:

• The Xcode list is busy, mostly with people complaining about having to learn. Grow up. kids.
• The book, for once, is written for a capable audience, an audience who have been here before and who mean business.
• Swift remediates errors in Objective C, in C, and in C++. No multiple inheritance, no pointers, no opportunity to confuse = and == in if statements. It has modules, so we can dispense with ObjC prefixing.
• Plenty of good ideas from other languages. Perl-inflected control structures, Ruby’s === operator and fondness for closures, Common Lisp’s hooks for methods called before or after mutators.
• What the early discussion I’ve seen misses is the very nice language support for null objects. That’s going to be a big, big win, and I suspect it’s a primary motivation for the language change. Weaning people away from ubiquitous nil checks will be a very good thing.

I don’t see any obvious reason Swift should be that much faster than Objective C. The popular coverage emphasizes execution speed, but I suspect that’s wool pulled over non-technical eyes. Some of the new features — range checks for boundary access, run-time type checking for downcasts, more reliance on call-by-value structs — come with modest performance penalties.

What I miss in the story so far is technical motivation: what are we trying to do, and what influences are we following? The introduction of Go, for example, was very good on this subject: we’re making life easy on the compiler so we can compile really quickly. ObjC didn’t have much motivation; it’s old, and it’s responding to old concerns. But Swift is new; a decent respect for the opinions of mankind should compel some statement of what they’re trying to accomplish.