Regarding Objective-C & Copland 2010

Copland 2010” refers to a series of articles, written in 2005, and a recent episode of Hypercritical, in which John Siracusa argues that at some point down the line Objective-C and the Cocoa APIs are going to have to be replaced with more modern technologies. Failing to address this sooner rather than later, as was the case with the Classic Mac OS, will leave Apple in a vulnerable, perhaps insurmountable, position relative to their competitors who have adopted “modernized” development technologies. Apple’s last-ditch attempt to bring modern technologies to the Classic Mac OS was codenamed Copland. Siracusa hints at the severity of the situation, if his argument turns out to be sound, by calling his projected development platform nadir “Copland 2010”.

In broad strokes: Siracusa is right and Siracusa is wrong. There are two parts to the Copland 2010 argument — a statement of the problem and a call to action with some suggestions. In the broadest sense it’s basically impossible to seriously debate the merits of the problem as he lays it out. Undoubtedly, at some point, Objective-C and the Cocoa APIs will be in the dust-bin of history. At issue, however, is the time scale. It’s unfair to hold Siracusa to 2010, in Avoiding Copland 2010, part 2 he writes, “I actually think the year 2010 is a bit too early, but I didn’t want to use a date that was too far in the future”. We’ll be fair and take 2010 to mean “near future”, in computer industry terms. Let’s call it between five to fifteen years.

I don’t think it’s at all likely that we’ll see the utility of Objective-C and the Cocoa APIs become totally eroded over the next ten years (the argument was first made in 2005, so we’ve used up five years of the near future). I do think it’s likely that during that period it will become more and more apparent what the next big thing is — where the industry is going. I don’t, however, think that any of the popular “modern” languages fit any better with the future of computing than Objective-C does. We’ll revisit this point.

Siracusa, during his Dark Age Of Objective-C episode of Hypercritical lays out the following criteria for a modern language:

  • Automatic memory management
  • Native strings
  • Regular Expressions native (but a library is acceptable)
  • Native object system
  • Named parameters
  • Succinct syntax for common operations
  • Acknowledgement of concurrency
  • Single vendor driving the development

I agree with most of these, as I think many developers would. We could quibble over the weights we assign to each but, by and large, that’s a decent list. Let’s use it as a score-card for modern Objective-C.

✓ Automatic memory management
Objective-C 2.0 can be garbage collected.

✓ Native strings
Objective-C has @”” strings which are mapped, via a compiler option, to NSString instances. If the requirement is for special operators to work on strings then I’d argue that’s actually an issue of not having a “succinct syntax”.

½✓ Regular Expressions native (but a library is acceptable)
Regular expressions are not native to Objective-C. There are libraries available and, as of iOS 4.0, Foundation includes a regular expression facility.

✓ Native object system
Objective-C has a native object system. Note well that Siracusa was not saying that everything had to be an object, he was referring to prototype based languages like Lua or JavaScript where developers roll their own inheritance systems.

½✓ Named parameters
The Objective-C message sending syntax provides half a solution to this feature. Ideally, one would want to simply name their parameters, omit any that aren’t required in the call, and have it all just work. While Objective-C doesn’t go this far it does go far enough to significantly increase the readability of any given message send.