After watching the eminently early and freely available WWDC 2010 session videos, I think my scales have finally tipped. It is my belief that Apple is definitely working on a new language to surpass Objective-C as their intended, primary, publicly recommended programming language, which I will call “xlang”.
Apple has helped take LLVM from a fledging open source project to a gigantic and successful undertaking. I used to be tickled pink when I saw a new language-related effort adopt some part of an LLVM project; now, I’m raising eyebrows when such an effort does not use LLVM in some way.
LLVM is at its core all about being virtual, which is to say neither tied to a specific architecture nor a specific language. That could just be a useful quirk of otherwise academic interest, except for the fact that lots of other connected architecture to handle Assembler and debugging, which is to say more and more of both the parts that interface with actual platforms and that border but do not intrude on pure compiler/JIT/optimization soil, has sprouted. clang remains a success story and its capabilities are amplified in Xcode 4, but it’s easy to forget that it builds on top of LLVM.
Everything that makes clang a great compiler could apply in spades to the theoretical xlang compiler because it would be free to exploit the fruits of LLVM without having to deal with prevalent tradeoffs. All the pieces needed for the low end is there, and Apple possesses either the remaining parts outright (libauto, Objective-C’s deliberately reusable garbage collector) or the wisdom and pluck to do a well enough, short enough job of implementing it.
Why now? Objective-C has steadily been improved starting a few years back and recently accelerating. But Objective-C both carries the millstone of existing code and platforms and the quality of being a thin layer on C. Despite the number of things that Apple seems to want to change, they just can’t willy-nilly. Changes will take ages to trickle down to everyone in the user base (non-fragile instance variables). Maybe iOS doesn’t have this problem now, but it will in the future, unless Apple really does intend to set a “run-to-remain” pace of minimal development for that platform when they have the chance.
And C is still C. Apple’s proud of continuously shaving off instructions of Objective-C’s inner workings, down to the recent objc_msgSend 16-method fast path. But Apple also knows that maintaining a layer that can’t break C robs them of productivity improvements and memory safety. How about an iOS version that could stuff strata of the memory set into cold storage, and simply keep part of your app running? Even if garbage collected Objective-C looks like it could solve that problem, it takes one NSValue object, or even simpler just the concept and functionality of a pointer to crush the dream.
So let’s say Apple really is into xlang. What would they have to gain?
They could gain a modern language with a modern environment, low-level enough that it performs at most of the speed of Objective-C and C. This layer could be thin enough to support the modern amenities responsibly. They could recover the freedom to define their own syntax and semantics. Nearly every Objective-C feature uses @keywords because they have to stay out of C’s hair, and C Blocks used ^ because they’re not overloadable in C++.
And last, but definitely not least, they could steer the vocabulary of the language heavily towards models they’d like to use. I imagine some mesh of C Blocks, messages and Go’s channels to play an interesting role. A lot of things that makes Cocoa great are rooted in asynchrony or separation of concerns, and an overriding model could go to town with several of the related concepts. xlang could gain a whole new API to Cocoa, a case of xlang being tailored to Cocoa instead of Cocoa being tailored to Objective-C.
None of this guessing (because that’s what it is) fools me into believing that Objective-C is going to go away tomorrow, or even within ten years. Being able to drop into C is too neat to go away overnight, which is why Objective-C will remain as the tool to use for that purpose. But in a world where programmers have side-effects, languages don’t remain perfectly applicable forever. I’d triple that statement for something that’s C, and triple it again for something that tries to go beyond C.
As someone who knows much of what there is to know about a higher level of abstraction, the alternative platforms, the current state of language and tools on this platform, and what seems to be on the horizon, I want to believe.
Inspired by, and hopefully continuing, Copland 2010 revisited. waffle apologizes for the inconsiderate but useful bundling of language, compiler, runtime and virtual machine in this article, and hopes that you get the idea.