waffle

Surpass

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.

I know all about MacRuby. I love Ruby and I love the idea of MacRuby, and I don’t think it’ll do in practice to actually succeed Objective-C in this capacity.

MacRuby hinges on being an alternative Objective-C (it calls the same APIs and uses the same object model to the extent of probably requiring some hacks to get Ruby’s object model to work the way it needs for compatibility) and inherits too many of the same potentially crippling properties.

It’s great, but when I say xlang, I do mean a clean slate. If Apple wants to do a clean slate, you had better believe it’s as clean as they can make it, and I don’t think repurposing a language on top of their own and current language runtime will do for that.

@Jesper so you think that Apple would prefer to rewrite all their APIs and come up with new concepts instead of keeping their existing APIs/frameworks and improve the programming experience using something like MacRuby?

Can you imagine the amount of work required to change the entire OS and make the switch to something totally new? I think that MacRuby is the answer for most developers who want a higher level programming language and only want to go down to C or Obj-C when really needed. Reusability, stability, maintenance and documentation are key, and MacRuby is promising all of that because it is based on existing robust technologies.

Matt: I have tremendous respect for Ruby and for MacRuby. I like and I love using both of them. None of this is meant as an insult.

My point was exactly that what if you want to go beyond “existing robust technologies”, head-first into new, robust technologies? If Apple runs such a project, MacRuby isn’t it, for just the reasons that you mentioned. I don’t think that Apple has ever been eager to do work that it doesn’t need. But I also think that Apple hasn’t ever shied away from doing what needs to be done (see the whole LLVM platform which is just now coming to fruition).

I think that such a group would be better staffed and be working completely in the dark until they’ve got something to show. With the level of resources Apple plows down into Objective-C relative to MacRuby (at least visibly), I can’t see that they wouldn’t allocate something on that scale for something that’s specifically anointed to replace it.

xlang wouldn’t have Apple throw away Cocoa. xlang would start out by making programming against Cocoa more consistent, and you’d be able to mix Objective-C (and MacRuby) with xlang’s new capabilities freely within your project. I don’t see any other route of migration.

My immediate thought was MacRuby, but I think you’re right that it would be a step in the right direction, but not necessarily the right direction itself.

I also have a concern that despite my preference for Ruby over Python, it’s looking likely that Ruby will be the Obj-C to Python’s C++.

It is something that’s been on my mind for a while – what would a new NeXT look like?

I’m not convinced that WebOS or ChromeOS are it – because I’m not convinced by the web technology stack as a general programming environment, although it’s certainly possible that parts of that stack could form part of something new – I can imagine a common layout engine being extracted from WebKit, even if they didn’t go the whole way to replacing .nib’s with CSS.

You don’t explain what about the WWDC videos has convinced you that Apple is working on a new programing language. If anything, their work on the Clang/LLVM suite, as well as the changes being made in Xcode 4 such as no longer needing to @synthesize, should tell you they’re committed to Objective-C.

Preston: They don’t have to stop being committed to Objective-C. Language support isn’t monogamy. Xcode 4 tells me that they have real, actual ambition to do brilliant things with the IDE, tilting towards the Resharper school of refactoring instead of the tax-form-like approach they have today.

One would think that they’d be interested in having a language handy where the language didn’t actively fight those features. This isn’t intentional, but the way some languages like C# and Java not only produce their output but specify parsing in which order of declaration is never important makes them much more convenient for these tasks.

Like you say, they’re extraordinarily committed to Objective-C; otherwise, they wouldn’t have taken the whole LLVM+clang+LLDB journey which is starting to pay off in spades now. All of that was groundwork to be able to do this type of editor. But they can’t build away every obstacle. And I think they will have a hard time settling for what will be reachable.

JulesLt: It’s interesting that the most forward-thinking people outside of NeXT were doing C++, while NeXT did something entirely different but based on the same idea, only unperverted (“and I can tell you I did not have C++ in mind”) and without holding back. I think this direction today points towards things like node.js and Newspeak. And maybe Scala. (Are you listening, n8?)

Martin Odersky responded at a recent Scala presentation in London to a question whether he can see Scala on LLVM that the project itself is too big for his team but he’d be very happy if Apple were supporting it.

Ultimately, I think anything Apple does will revolve around multiple languages working with Cocoa. Yes there are a few issues, but on the whole Cocoa and Cocoa Touch are extremely well designed APIs. Any future language won’t be to replace Obj-C but to offer an alternative, much like what MacRuby is trying to do.

The issue is that Obj-C has some fundamental design decisions which makes it such a good language:

Ability to drop down to plain C at any time. C is going nowhere and is still one of the best ways of writing fast code

The belief that the language should be simple. If you look at a lot of languages, they have a lot of features and syntax to go along with those features. Obj-C is an incredibly simple language. Now to some degree it can be too simple, I’d love if arrays, dictionaries, sets and numbers were as easy to create as strings. But I wouldn’t want to add other ways of accessing values in those items.

Duck typed with optional static typing. It’s not 100% perfect, but it is by far and away the best implementation of this sort of typing and is probably the most flexible. The fact is that the compiler can help you catch things, but in a heavily runtime based language it doesn’t know best.

Interspersed arguments. This wipes the floor of argument lists and named arguments in the readability department. Yes it takes longer to write but writability isn’t something you should care about as much, especially with an IDE with autocomplete.

Any replacement would have to support all of these things. But another language that complements rather than replaces Obj-C would have far more freedom.

My guess for what xlang would actually look like is rather close to Objective-C without the C. I have a hard time imagining that to begin with because it’s so familiar, but there are the obvious upshots of the Objective-C parts, the ones that didn’t have to maintain any pretense of C-likeness, that could be the core of xlang, as you say.

Points 2..4 are part of what makes Objective-C great. Point 1 is what you can’t remove. That’d make Objective-C not Objective-C, because much of it is just C. But xlang could be based on all the best ideas from Objective-C, done in a much better way, and you could use part xlang and part Objective-C so that you wouldn’t have to miss out on what you need from C nor be bound by its constraints on every line of code.

I would tentatively like to throw the idea of C# being the replacement language into the ring. Why re-invent the wheel? Java is a fantastic language, but due to political reasons Microsoft decided to create a new Java, and they fixed a lot of omissions along the way… making C# one of the most advanced languages in use today.

MonoTouch shows how easy it would be to have C# adopt the current Cocoa API and go forward from there, and Microsoft would probably welcome the idea of teaming with Apple against Google in this space. After all, Microsoft is in a distant 5th or 6th place right now in the mobile space, but has this great asset at their disposal…

I reckon they’ll keep objective c as a source to maintain backwards compatibility but use something like the fonc project’s cola languages to allow source from any language you like to produce much better optimized assembly than current c compilers can. Because the fonc projects translators would allow source and targets of any language type in an optimized way…

I’ve noticed that Apple has been removing the old tool chain piece by piece and replacing it with modern equivalents.

I do believe the next language will be Ruby. Creating a new language from scratch just wouldn’t work. Languages don’t get created in isolation. They need to meet the real world for years and be morphed before they become useful.

I don’t think you could release an xlang and have it be polished and useful on day 1 when it is released.

My immediate thought is a reworked version of JavaScript that compiles into native code with all the power of llvm. Apple is already highly involved into the web with webkit. They probably want to go further.

apple technologies are known for having secret double lives ;) i can actually imagine all cocoa apis doubled in something else. to me objective-c often feels tedious and as a giant C afterthought. it has an awkward syntax (especially given the underlying C spec) and apple are probably well aware of this.

removing C would be kind of easy once there’s no need to fall back to the white threads of underlying osx/bsd tech. but the real value might just be in attracting the programmers who are otherwise put off by the [object message] concept, as well as points 1,2,3, and especially 4 in comment #14… a lot of creative people are among this folk.

Jesper, i don’t think you answered Preston’s question: what in the videos makes you think they’re working on a new language? Apple is a very hard-headed company, and they not going to create a new language just to make refactoring easier.

An Obj-C replacement without C? Wouldn’t that mean re-writing the whole OS since most of the low level code is C. One of the coolest things about Obj-C IMO is that you can intermix C into it and there by having access to lower level api’s. So is C# the example that should be looked up to? That’s horrible IMO. And Ruby, common, a scripting language.

I’m still not clear what it is in the WWDC video convinced you that Apple is working on a new language. Apple’s work on Clang and the additions to Objective-C in 2.0 suggest they’re firmly committed to it. Objective-C being a thin layer over C, which you cite as a millstone, is one of its big advantages. My opinion is that Apple will just continue refining Objective-C and it syntax, as they have been doing since Leopard. Steve Naroff at Apple has said their model is to use C-based languages as the foundation and scripting languages on top.

Preston: “He would, wouldn’t he?” doesn’t make that comment go away or magically make my scenario valid. But if Apple is developing a new language, they wouldn’t announce it before it could do triple back-flips either.

I’ve replied earlier to what exactly, and the simple answer is that there’s not one timestamp in one video; rather, it’s the kind of things they’re now able to do with Xcode 4 and beyond, and that even with all this work, they’d be able to do a lot more with a language and environment that’s not as shackled to C.

foo (comment 25): Rearchitecting the OS is not a requirement in any way, I don’t want for xlang to be C#, and dismissing Ruby because it is “a scripting language” is as stupid as dismissing Objective-C because it is “too low level”.

Dr No (comment 24): Nope, I didn’t; I did now. I didn’t approve Preston’s comment manually; anyone who’s commented before is pre-approved.

george (comment 23): There’s no need to leave out everything, but keeping Objective-C around to interoperate with the nastier parts of C rather than porting every nasty part to xlang is an approach I’d favor.

Felix (comment 22): I like JavaScript more than most people, but I also don’t like its actual oddities (rather than its prejudiced oddities). Douglas Crockford, the extractor of JSON has written at some length about this.

interesting analysis and I think you might be onto something. I wonder if apple is looking into functional languages too. erlang, haskell and odd but interesting things like mythryl have gained a lot of traction outside of the mac ecosystem.

It’s stupid eh, ok how about execution speed. Do we want fluid graphics and multitasking. My comment about implications for the os is that a lot of the obj-c frameworks are built on top of lower level C api’s. Obj-c’s light nature should make this smother than shoe horning in ruby in it’s place.

I don’t know about a totally new language, but I think it would be nice to see Python get more focus. It makes it easy to drop into C, it can interface with Cocoa via PyObjC, and it uses reference counting much like Objective-C.

foo: The state of the art in C# and Java VMs are plenty fast enough and in some cases, the jitted code can be more optimized than the compilation that happens ahead of time. There are times when the speed difference really does matter. I will bet you large sums of money that in most programs the difference is negligible and that there are people who are willing to take the tradeoff in order to gain a language where you won’t have to worry about tripping over so much stuff, and where you can formulate problems that you couldn’t before.

I don’t want for everything to forever be dependent on past decisions. Many things are possible that weren’t before; many other things have been possible for years that we’ve just decided isn’t possible anyway.

There will be things that Objective-C will still actually, indisputably be the best at, which is why I hope Objective-C will stick around to do those jobs. But I also have a hard time thinking that something we can’t even imagine now won’t be better at a lot of other tasks, some of which we already do and some others which we can’t imagine either.

I tend to agree that they will roll their own “language” (i.e. syntax). I think that will prove a mistake based on hubris and secrecy. Programming language design is human interface design. People tend to forget that Python grew out of research into what syntax, etc. worked well for beginning users. Unsurprisingly, the result turned out to work really well for sophisticated users (and was a major influence on Ruby as well). 8 ultra hard-core senior Obj-C guys averaging 17 years experience and eating their own dog food are not the ideal set of test subjects, at least not if Apple is hoping to extend the productivity of developers with much less experience in general and much less Obj-C experience in particular. (And yes, I’d be thrilled if they proved me wrong, and yes, iOS is a real achievement in newbie-friendly UI.)

Just to add a little fuel to the fire of Jesper’s hunch/educated guesses: At the latest WWDC there were no sessions on OS X 10.7, ostensibly because Apple wanted to put all the focus on iOS. And judging from the reports of attendees willing to break their NDAs, there wasn’t any discussion with Apple engineers of what exciting new developments to expect in the next OS X, not even minor incremental improvements.

This either means that Apple has stopped any serious development of OS X for Mac or is doing a lot of serious work in secret deep in the labs under Cupertino. I can’t imagine Apple totally dropping development on one of its crown jewels. (Despite iOS devices coming to the fore, Apple still sells a lot of Macs. Mac sales still account for a respectable 26% of Apple revenue. Anyway, I really don’t see Apple dropping the ball on one of their cash cows.

I think the real question is what are features that look ‘odd’ today but feel right. There is no question that intermediate code for interpreters is by far fast enough for the typical App on your OS, and if not you can alway practice your C-Skills.

I really like F# and Cloujure. As functional programming speeds up C# and Java somehow feel outdated. If it’s just about a C# like language, than Cocoa is just good enough. And then it’s hard to see a point in Changing the language.

Microsoft had/has to get rid of COM and the win32API, this is not the case for Apple, Cocoa is a great Pattern rich API and does not cause the endusers any trouble. If you shift languages there must be a paradigm shift, else I see no real point to this.

Sam: GCD isn’t a language, granted, but it turned out a better API than most other practical approaches for managing concurrency that I’ve seen. You’re right that the chances for outside acceptance and even catching more or less obvious errors right out the gate drops considerably, which is something Apple’s had issues with historically.

Floyd: Good point. I believe that “just” doing these changes to xlang in isolation will have been worth it (especially because they’d keep Objective-C around), but I’m not necessarily certain that everyone else will make the same judgement, which has been demonstrated in this comments thread.

I think there’s something else to go along with it, or something that xlang would actually enable (maybe in a non-painful way) to begin with. If xlang is indeed under development, Apple has the luxury of seeing this and the rest of us may be able to just barely suss out trends. I certainly didn’t see either GCD or OpenCL coming.

I’d like this very much if they made it very easy to call regular C/Obj-C code. The problem with many languages (Ruby & Python) is that calling C is a pain. Ideally I’d love to just have my C/Obj-C files in my XCode project and be able to call them as if they were XLang or whatever. i.e. the transition between managed code and unmanaged code should be fairly seemless.

Clark: Exactly. I see it working like this: xlang and Objective-C share an object model. Possibly, xlang’s is more advanced or has access to other things (like some channel-like abstraction for asynchronous calls), but you can talk to Objective-C and vice versa using that subset, and of course the Objective-C part can continue doing whatever it does today.

That way, there’s full interoperability on the object-oriented strata, and xlang doesn’t have to tie itself up in C minutia. This probably means that for xlang to partake of something, you’ll have to “wrap it inside an object” — if you want xlang free of C stuff and you want to pass a pointer to a struct with a union of two function pointers, that’s about the only way that’ll happen — but from previous experience I’d rather have this solution. Simple, straightforward and forces you to draw lines across subsystems or layers rather than share “half classes”. With two languages for the same class, that’d suck to maintain regardless.

I think if they choose to move/add another language it wouldn’t be an existing language like C# or Ruby. Since Apple is about the only company using Obj-C they have a lot of flexibility in developing it. I think they’d want a level of control for any new language they choose. D language might be interesting. I read an article on the design of it a couple months ago and it seems really well thought out. It’s missing a couple features that I think it would need, but it really seems like a step forward over existing languages.

Jesper: concurrency is exactly the sort of problem you would expect a tiny group of wizards to solve well, and an API is emphatically not a language. WRT “outside acceptance”, my point was somewhat different: I assert that the biggest benefit of a successful VHL-for-iOS/Mac OS X will be increasing the productivity of those who have yet to climb the Obj-C learning curve. If all the new VHL does is to make the existing set of competent Apple-platform programmers say 2x more productive, that’s nice, but a huge missed opportunity. If OTOH it makes casual Apple-platform programmers more productive (especially by creating new Apple-platform developers from people who simply will not learn Obj-C), that’s a much more valuable achievement. I fear that the second achievement, because it requires Obj-C true believers and compiler/VM hackers to treat the needs of casual programmers seriously, will not be attempted. There are real conflicts of interest between the 2 sets of developers that don’t exist between, say, power and novice users of iPhones.

I think one of the best reasons to start over is to pave a better foundation. For example, “casual programmers” may be weaned on languages like Java or C#, both of which have much more powerful refactoring support available from various tools. That requires some thought and much better access and is not just a tooling issue.

In anything that builds on C, you can change the environment (what’s available at any given moment) pretty substantially depending on what you include in any given order and what those things in turn include. Finding references accurately demands the core from a compiler and the knowledge of a full IDE – you need to know exactly what’s being built or you may not find everything, and if you miss gathering a reference, many refactorings will be practically useless. In Java and in C#, when you compile something, the entire package/assembly is essentially in for consideration at the same time. There’s a whole magnitude of problems that just don’t exist.

I’m not really sure how you separate a “casual” programmer from a “competent” programmer — the one will turn into the other at some point, and you didn’t specify breadth of project, level of ambition, sharpness of convolution… I’ve seen “design patterns” fuck up more than one project completely unnecessarily.

If your point is “I hope xlang isn’t just the intricacies of Objective-C made more intricate because now they aren’t constrained by C”, I hope not and I should hardly think so. Many things that are intricate are so because of the way it has to integrate with C; I think the language would at least get clearer. But xlang could certainly go any in a number of directions with regards to syntax and vocabulary, some which will be confusing.

Are there many historical examples from Apple’s history to draw on (ESP. Examples from how the OS has progressed this far?)
The Intel transition (and specifically the rules of engagement that Jobs details at the keynote) speech seems to be one example of the ability to skunk work such a big transition. Do the current or recent updates and changes fit in with being able to be part of a larger plan/ ready to slot in to future changes? (GCD, OpenCL)
OpenCL seems to be a good eg of Apple whooshing through a spec to Khronos – (though I don’t know how good it is,the rate of getting it out there was considered fast, after being kept secret for some time (see Light Peak and other hardware specs too).
Looking at the OS cycle, aren’t we likely to hear more (beyond Foundation changes) about 10.7 soon enough? (not that they don’t have enough on their plate!)

Jesper, if this new language would replace obj-c then it would have to be built ontop of c, making it a c like language not something like ruby. If it’s not replacing obj-c then it’s more of a parallel language and perhaps that is where macruby will end some day but intermixing lower level c api’s inside ruby will get ugly, so it’s still going to be a second citizen. I think it’s more likely that we will see an obj-c 2.1.

My comment about speed was made under the assumption that you meant a replacement of of obj-c, in such a scenario all apps would be written in this language including many system apps, that could easily add up to slow.

“they’d be able to do a lot more with a language and environment that’s not as shackled to C.”

But again, why would Apple spend years investing in a replacement C/C++/Objective-C compiler for GCC if their future development environment does not involve C? It just seems like all signs point to the opposite of your conclusion.

Objective C is awesome, except for the awful syntax. MacRuby is very close to nirvana, and I’m pretty sure Apple could make Ruby the next main language if they wanted to. Sure, Objective C would stick around, but it would only used for super high performance code, drivers, and other special projects. I love Ruby, and I think Ruby shares the same values as Apple: powerful, clean, simple, elegant, and at times a tiny bit quirky.

However, knowing Apple’s thinking about competitive advantage I wouldn’t be surprised if they decide to create a brand new language. They own the dominant mobile platform and if everyone uses Apple’s custom language it gives developers one more reason to develop solely for iOS devices.

In the midst of all of the iPhone’s and iPad’s success it may not be apparent that Apple has a serious problem today: iOS development is not productive at all. You need to hire very expensive, hard-to-find developers to write good iPhone software. One bad developer can easily ruin the stability of the entire application, and bugs can be hard to track down. A new language would solve this problem and bring the same elegance of Apple’s products to the development tools. WWDC 2011? I sure hope so!

Preston: Even if they wanted to, those tools are not going to go away overnight. They can still introduce a new language and point to it and say “this doesn’t involve C and thus will probably be easier for you”. They can do that while never, ever stopping to support their family of C languages. Apple can do two things at once, I promise.

So it sounds like most people like a lot about Objective-C, but that the C language and backward compatibility is what is holding it back. As long as we can still link to C code there is no great need for C compatibility. Undoubtedly it has been a big help in reducing the learning curve for new users, but some things are showing their age.

I’d be more than happy to see the end of preprocessor macros. It’d also be useful to remove the header and implementation split. Declaring properties in one place would be really nice. Separate interfaces do have their uses, but we have protocols for that. I’m sure a lot of people would like namespace support, but in practice this just doesn’t seem to cause any problems today.

I suspect one of the biggest motivations for a new language is so that Xcode can have a deeper understanding of the code and safely perform all sorts of refactoring or code generation actions that are just not possible today. That’s one of the biggest gripes of Java developers coming across to Objective-C.

Personally I’d like to see Apple adopt UML more in Xcode. It could help unify a lot of discrete tools that are currently there but not used much. It’s be nice to be able to move up a level in Xcode and work more on modelling applications rather than just typing code in to text files.

It’s also possible that Apple is working on a Cocoa based ABI standard. That would allow any conformant language compiler to directly interact with Cocoa.

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.

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.

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. ;)