waffle

Things I did not say in Surpass:

• That Objective-C will be taken out back and shot.
• That Apple will need to drop C-based languages.
• That Apple will need to drop Objective-C.
• That Apple will need to stop supporting Objective-C as a language for application development.
• That Objective-C sucks.
• That Cocoa needs to be laid to bed.
• That Cocoa needs to be rewritten.
• That people would need to use either xlang or Objective-C to write one program.
• That xlang is basically { LISP, Nu, Smalltalk, Ruby, Python, … }.

My premise was always what I’m about to describe, but I think I didn’t explain it well enough. Let’s start by saying that Apple would keep Objective-C on-board. The xlang scenario is sufficiently fantastic that them just dropping their existing environment would be too incredible, beyond plain stupid. I’ve been thinking — and hoping — that Apple may be doing something like it for years. I’ve been finding it more and more plausible since at least 2005. The scales dropped in my mind when I saw the WWDC advances not because they were big changes, but because they were the right kind of small changes, the right sort of hints.

Most people don’t get why I see the need for a new language at all. And they’re half-right, even: the intersection of a well-supported, stable MacRuby and an Xcode with less brittle and better implemented Objective-C support (including refactoring) would serve the vast majority of my own needs in languages I already enjoy. I think there’s an angle to why Apple would want to do this, I think that angle is interesting and I think it’ll have consequences for me when it happens. If. When.

Here’s the thing, again. Imagine Objective-C. Imagine Objective-C without C. Can you do it? I can’t. Objective-C is a layer on top of C. It never got to define its own primitives, it never gets to escape the pile of rope that is C pointers, and backwards compatibility limits what can be added on top.

Blocks are a good example of the position Apple is in – they did manage to add them, for which I am eternally grateful. But look at the collateral damage: you have to copy the block if you pass it elsewhere, you have to reference count it, you have to swallow, count to three and close your eyes every time you want to define a block variable, typedef or parameter due to the consistent but horrible syntax. You have to cast, or explicitly specify BOOL, every time you want to return boolean, because BOOL is just a typedef’d signed char, YES is just 1 cast to BOOL, and type inference isn’t smart enough to figure it out. There are worse things in programming, and my point isn’t that I can’t handle nuisances, but that blocks aren’t all they could be. For example.

So imagine what the good things from Objective-C would look like if Apple could define the entire language. Imagine what they would stick in, knowing what they do now about being tight on memory, fast on dispatch, and consistent on asynchrony as a good, overriding paradigm for scalable programs. That’s what I hope xlang is.

It’s also entirely possible for this to be mixed with Objective-C within one app — Objective-C and MacRuby get along fine, don’t they? When I said “surpass”, I did qualify it as “their intended, primary, publicly recommended programming language”, never as the “only” one. Let’s again take Blocks; you can write Snow Leopard or iOS 4 code without using them, but they help greatly. Let’s also take QuickTime: when they added a 64-bit API, it was only accessible through QTKit. People working with 32-bit QuickTime didn’t lose anything, but Apple didn’t have to keep doing things the same way as in their oldest surviving non-deprecated API.

C isn’t going to go away. Objective-C isn’t going to go away. There’s a way to recognize both those things and see that a new language could be modern, stable, small, fast, and provide better models and abstractions.