All kinds of things compile down to assembly. Binary compatibility between two programs doesn't say anything about how easy it would be to translate their desi

All kinds of things compile down to assembly. Binary compatibility between two programs doesn't say anything about how easy it would be to translate their designs into other languages (which is often a new way of thinking), or different standard libraries. Many approaches are possible, few are worth the effort. If Apple proposed a new language that didn't support message-passing syntax, and the only way to keep Cocoa dependencies working was with a pile of objc_msgSend() calls and other low-level wrappers, developers would just laugh at them. A single line of Objective-C often contains 3 or 4 pairs of square brackets, and objc_msgSend()-ifying that alone would be a nightmare even in the short term and even with a code generator. That's why I said, the new language has to follow the same calling conventions. Fundamentally, whenever I see "setFoo:x toBar:y withBaz:z", I should be able to either leave that alone or do very little to that line of code. Carbon-to-Cocoa was feasible because Objective-C is a superset of C (plus the libraries did share some things, like free casting between the CFStringRef and NSString* types). Not only that, but there's a compiler for Objective-C++. It was very easy to adopt. So to follow the Carbon-to-Cocoa model, Apple needs a new language that's a superset of Objective-C. And that's actually something I'd like to see.