Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.


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.

Before you comment, please also read this clarifying post.


  1. Unless you can get rid of C, there is no need for another languages. ( Which we tried for the nearly 40 years!! ) Objective C offer the best of both world, the power of C and high level languages features.

    Look around the world, Nearly All Low Level Programming, Encoder, Decoder, Hardware Related like Drivers, OS etc are all still programmed with C.

    The Languages you are looking for already exist in the form of Go or D, with some features on and off as you like.

    Even if apple wants a new Languages, It would be better to guide the new C1x standard. And then evolve the Objective-C. Or even better would be to add Objective C as a new extension for C1x standard.

    For Other programming needs. Lua fits the bill very well.

    By Ed · 2010.07.07 21:45

  2. Could Apple have been running a Star Trek-style secret project with Dylan this whole time?

    Naah, probably a Scala frontend for LLVM..

    By Dr. Kenneth Noisewater · 2010.07.07 22:43

  3. I personally would like to see multiple inheritance done well, something on the order of Eiffel. Eiffel is surprisingly clean and powerful.

    Like concurrency, multiple inheritance is hard to do right, but potentially very powerful. I would like to see what Apple could do with it…

    By Alex · 2010.07.08 00:00

  4. Ed: “It would be better to guide the new C1x standard” in which way? If they wanted to work around the parts of C that are holding them back, no, it wouldn’t. They’re running low on low-hanging fruit, and while they can get more involved things done (like Blocks), they can’t escape C, its fundamental design choices and their own need for backwards compatibility.

    By Jesper · 2010.07.08 00:15

  5. I’m thinking about the difference between API and Language. Isn’t it a good idea to move more features from the API to the Language if it happens you own both, are good in architecture and eat your own dogfood, why not design it that way? So naturally a new (Language&API) would be a layer on the lower level APIs just like Cocoa is a Layer on top of CoreFramework.

    To the whole C is my favorite debatte: Nobody can kill C, and many have tried. But you can free new Programmers from the need to know it in depth.

    Also you can use a language much better than a Framework to enforce Patterns and Best practices in a natural way. There is something about the new strength Apple posesses and uses in the AppStore that I would like to see executed in a new API. ;)

    By FloydThreepwood · 2010.07.08 13:38

Sorry, the comment form is closed at this time.