Regarding Objective-C & Copland 2010
So, in the end, while I appreciate the thinking behind Copland 2010 I don’t believe it’s quite the issue Siracusa believes it is. Objective-C continues to evolve, and in directions I believe will be increasingly important in the future. I don’t believe we’re anywhere near the level of crisis that Apple hit with Classic Mac OS and I don’t believe that a total second-system re-write without a clear goal is the best prescription for the platform.
Siracusa’s original piece was written after a long period of near stagnation in Objective-C. Apple has since made major improvements to the language such as garbage collection and blocks. Objective-C and the Cocoa frameworks could still use a lot of work, but I don’t think they’re approaching the edge of a cliff. There’s room for continued evolution. If Apple keeps working on it, I think they’ll be fine.
A distinction that’s not commonly discussed is that, although Objective-C provides automatic memory management via garbage collection (on Mac OS X, but not iOS), it is not a true managed or safe language like Java, C#, or Python. It’s still possible to have bad pointers and to reference memory that has been deallocated, and this leads to unexpected behavior or a crash, rather than a NullPointerException or an AttributeError. Likewise, an infinite recursion in Objective-C will crash rather than produce a StackOverFlowError or RuntimeError. Ideally, it would not be possible to call a function with the wrong number or type of arguments.
At this point, Objective-C’s hybrid nature is probably a plus. However, I would like to see it evolve in the direction of increased safety. Microsoft seems to have a successful transition strategy, where managed and unmanaged code can be mixed in the same application while remaining isolated. A successor language from Apple could potentially remove the unsafe C parts and compile down to a VM but still call into classic Objective-C where needed.
7 Comments RSS · Twitter
The thrust of my xlang theory has, as you say, not been that Objective-C or Cocoa is going to fall off a cliff, but that *sooner or later* (and we could be reaching into the tail end of this decade), they're going to want to do some things about the parts of the C mythos that they can't solve by adding parts to Objective-C.
Apple has got their head screwed on tight enough that someone's thinking about things that far out. For example: Xcode 4 was in development for years and while it was somewhat apparent that Xcode 3 had stagnated a bit, they could just as well have been busy enough with iOS platform building to block any monumental progress. We saw Xcode 3's faults, but we didn't see the massive upheaval of most parts in Xcode 4.
Apple's putting a great deal of investment into compiler/runtime technologies, and has for years; LLVM is precisely the system that will allow them to gradually move from an unmanaged to a managed system, and from Objective-C to a better language without breaking backwards compatibility. One reason Xcode 4 took so long was that Clang needed to be usable enough first to serve as an incremental, error-tolerant C/C++/Objective-C parser and compiler; otherwise you'd have ended up with a bizarre hybrid that gave you different results depending on the source language. (Clang is about 5 years old now.) As is, I think the refactoring bits of Xcode 4 are still the ancient hacked-up versions from Xcode 3, since Clang's refactoring support isn't quite there yet; this will obviously change in future.
While static analysis and refactoring will get you some of the way towards evolving Objective-C code, runtime safety is of course still an issue. SAFECode (http://safecode.cs.illinois.edu/) is a system built on LLVM that attempts do this, in fact. Right now it's patent-encumbered (so it can only be used in research) but there's work under way to make it independent of the infringing code (DSA). It's been used to execute a version of the Linux kernel, so it's not entirely incapable. (I mentioned SAFECode to Siracusa in an email following his original podcast, but did not get a response.)
Nicholas: Every time I see this point brought up where, roughly, "Objective-C and technology X will span the distance", I ask myself what will have to give. Something has to: perfect backwards compatibility and continuing to be a perfect C superset means you can keep doing everything you could do before. If you add protection to a new system, that obviously means different behavior in some cases.
Apple is progressive, but they are still squeamish about backwards compatibility on the language level or they wouldn't remain C-based in the first place; there's no way they'd take the necessary hacksaw to Objective-C's defined and supported capabilities for this to be the only mode to write Objective-C code towards.
Don't get me wrong: it'll be thoroughly interesting seeing something added like SAFECode.
Right, that's why I mentioned some combination of a safer language/runtime (with a pretty easy/automatic transition from Objective-C) and a compatibility runtime which can enforce memory safety on code not explicitly written to be safe. The parts of Objective-C that look like Smalltalk will obviously have a better chance at the former than the parts that involve assembly and pointer arithmetic. To mention another current project, consider embedding something like Google's Native Client (in its portable version, another LLVM-based project) as a backwards compatibility layer for C code. The selling point will probably be something like "your pure C code will run a little slower, but if you use Objective-C APIs then you get all these great new language features, and your code will run faster because we can optimize it at runtime". (Once a real runtime gets underneath Objective-C, it'll be able to eliminate dispatch overhead, inline through message sends, even do trace-based JITting and so forth.)
Point taken, but even Objective-C APIs use "C-isms" in many places. There's no non-C way of handling variadic methods, for example, not to mention secondary return output pointers and C arrays or buffers. If you restrict pointer buffers in particular, what happens to NSData?
You certainly can limit it to the safe subset of all that. If someone ends up doing that with an eye towards preserving the uncontaminated parts of Objective-C APIs, it'll be interesting to see where they draw the line.
I'm working on something like that.
I'm hacking DMD (compiler of the D programming language) so that it can generate Objective-C classes natively and interact with Objective-C code. And for the most parts it already works. You can define Objective-C classes as if they were D classes and work in a more strongly typed environment. I still need to implement memory management and add support for categories, but it's very nice to see most of D's natural features available for Objective-C classes. Here is an overview of the things planned:
https://github.com/michelf/dmd/blob/d-objc/objc-notes.txt
My impression is that MacRuby either is that successor language, or is laying the groundwork for that language.
