Hypercritical
Avoiding Copland 2010: Part 3
Pondering a successor to Objective-C and Cocoa.
This is the third, and probably final installment of the “Copland 2010” series. Be sure to read part 1 and part 2 if you haven’t already. To briefly summarize, I’ve speculated that the Objective-C language and the Cocoa API are the parts of Mac OS X that are most in danger of falling behind the competition five to ten years from now.
Yes, there remains some contention on this point, but even those that disagree might be able to participate in this final chapter. After all, everyone can agree that Cocoa and Objective-C will be obsolete someday. Okay, maybe someone out there thinks that won’t happen until in the year 2050, but someday, right? Today I’m going to ponder what to do when that day comes. What should replace Cocoa? What can replace Cocoa? What’s Apple’s next big move in the language and API wars?
For better or for worse, the other players in the market have already placed their bets. Sun was the first out of the gate with a successful memory-managed language. Java has had a lot of success pushing the adoption of high-level languages, especially in the world of server-side software. Microsoft learned from Java’s mistakes and produced C# (albeit after a brief pit-stop to beat-down Java in the desktop software market and then pay-off Sun in order to re-normalize relations).
On the API front, Java has already been through a few iterations. So far, Sun has been unable to make a dent with its various Java desktop APIs. Unlike Apple and Microsoft, Sun does not own a desktop platform with any appreciable market share, which makes their efforts in this area all the more difficult. But more than that, Java’s desktop APIs haven’t been that great. They started off on the wrong foot (to put it mildly) with AWT. A few years later, Swing emerged, restoring competence but still failing to show the world anything really new.
Microsoft has also been through several cycles of the API wringer with C# and .NET. The decision to promote and then essentially deprecate WinForms was a particularly embarrassing bump in the road. Today, Microsoft seems to have its story straight, pushing WinFX and WPF for Vista.
Since both Sun and Microsoft have already put in several years of hard work, why shouldn’t Apple just jump on one of those bandwagons? Going it alone has really hurt Apple in the past. Why not let someone else clear the way this time? I’m sure either camp would gladly accept Apple’s support.
Despite the allure of ready-made solutions, adopting any competitor’s language technology wholesale is a bad idea in this case. Java may be standardized, but Sun seems determined to hold the reigns of that standardization. C# is more open, but Microsoft is still the driving force. Microsoft also has disproportionate ownership of C# compilers and tools, which is not surprising for such a young language. All of this adds up to some substantial strategic risk for Apple, were it to adopt the C# or Java language wholeheartedly. And this is before even considering the technical merits of those two languages.
As for APIs, you can just forget about adopting a competitor’s API in any form. That’s a lose-lose proposition now matter how you look at it, politically or technically.
Finally, consider that Java/Swing and C#/WinFX are both immature and relatively untested on the desktop when compared to Cocoa, which has its origins with NeXT in the late 1980s. Sun and Microsoft started later than NeXT, which gives them an advantage in technology, but is a disadvantage when it comes to maturity and polish.
While both Sun and Microsoft retain essential rights to parts of their respective technologies, both also have “public” or “open” portions as well—depending on how you defined those terms, of course. But the bottom line is that there are technologies that Apple could borrow (or, at the very least, license) and then re-brand as an Apple technology.
We’ve seen this a lot in Mac OS X. KHTML plus KJS became WebCore and, eventually, WebKit. XHTML plus JavaScript became Dashboard. Even Mac OS X itself has been assembled from existing, mostly open technologies: BSD, Mach, Samba, Apache, OpenStep, and so on.
Apple’s made some quirky choices in the past (e.g., going with KHTML instead of the higher-profile Gecko), and it’s worked out well for them. So it’s worth considering technologies outside of the “obvious” Java and C# realms. Several comments posted to the first two parts of this article went down that path. What about Lisp or Smalltalk, for example? Both languages are open enough to borrow and re-brand, and both are “managed” languages in the modern sense of the word.
There are definite mindshare issues that go with the quirky choices, however. Few have a desktop software developer base that’s even as large as the relatively small NeXT/OpenStep camp was. On the other hand, Apple is pretty good at turning a difference into a strength. The quirky choices have the advantage of not looking so much like Apple is playing catch-up, and more like they’re playing leap-frog.
The more difficult alternative to scavenging existing technologies is to do some primary research in this area and come up with a complete solution in-house. But for better or for worse, Apple’s not really that kind of company anymore.
In years past, Apple was said to be afflicted with NIH, or Not Invented Here syndrome. Everything at Apple had to be created by Apple itself from whole cloth. Sometimes it was good (QuickTime) and sometimes not so much (PowerTalk).
These days, it’s exactly the opposite. Basic R&D has been slashed at Apple. Few things that do not directly contribute to a current or future product are considered worth doing. Adding value to existing, proven technologies is now the order of the day. Call it NIE, or Not Invented Elsewhere syndrome. Like NIH, this can be both good and bad. In the Mac OS X era, it has been mostly good, so it’s hard to fault Apple for sticking with a plan that works.
(As an aside, back when Apple was doing research in all possible directions at once, they actually managed to create a high-level language of their own, named Dylan. Dylan is an obscure, mostly forgotten language that never really took off—obscure, that is, until some recent news brought it back into the limelight briefly. Odd timing.)
Anyway, despite my desire to see an increase in primary research at Apple (if not necessarily a wholesale return to the “glory days” that spawned Dylan, OpenDoc, QuickDraw GX, et al), my recommendation is for Apple to take the Safari/WebKit approach to the memory-managed language issue. Evaluate C#, Java, Smalltalk, Lisp, and heck, even Dylan. Look at everything that’s out there. Grab the the bits and pieces that are the best fit for Apple’s needs, assemble them into a cohesive whole, re-brand the whole thing, and go to market.
On the API front, however, I think Apple should turn to its in-house talent. Sure, learn from WinFX, but then give the people behind Cocoa a chance to design a new API around the new memory-managed language. Let them correct the mistakes of the past and create an API based on assumptions that make sense in 2010 and beyond.
So, problem solved, right? Get to it, Apple! Ha. I recognize that my recommendations are so vague that they’re nearly useless. It’d be a lot more useful to say something like, “Apple should adopt C# and CLR via Mono, then port Cocoa to C# and make that the new, official API of Mac OS X." The problem is, I don’t know enough about all of the high-level languages and VMs that are out there—or about Apple’s capabilities and staffing—to make any kind of concrete recommendation.
I will say this, however. My instincts tell me that both C# and Java are too low-level. Yes, they both have fully automatic memory management, and both eschew C-style pointers for the sake of safety and security, which is more than can be said for Objective-C. But the runtime that Objective-C uses to do its “object stuff” is arguably higher-level than either C# or Java, both of which still seem to cling to charmingly retro notions of compile-time optimizations and “efficiency through bondage.”
I also think their respective VMs (CLR and JVM) have problems. The JVM is tied too closely to the Java language to be a good general-purpose foundation, so it’s out of the picture unless Apple really wants to go with Java as its high-level language—something I recommend against, for other reasons. Both CLR and Java lack native support for common high-level language constructs like strings and bignums. Finally, I really do buy the argument that stack-based VMs (like JVM and CLR) are not a good fit for today’s hardware.
Yes, it’s obvious that my extended exposure to the Parrot project has warped my mind to some degree. And yes, Parrot’s development process has been a bit of a train wreck. But despite the drama and the delays, I really do think they’re onto something with idea of a register-based VM designed to support really high-level languages like Perl and Python. Could something like C be hosted efficiently on the same VM? Probably not on Parrot, but I think it’d be possible on a similar VM designed with that task in mind. Fast, low-level features for the oldies, rich, high-level features for the newbies. I think it could all fit in One True VM. Maybe.
Anyway, I hope you can see why my advice has mostly been about motivation and process, rather than any particular choices. I have my vague ideas and instincts, but that’s no substitute for a real evaluation of the options. I don’t envy Apple’s task when it comes to making this decision.
Speaking of which, having said (sort of) what I think Apple should do, here’s what I think they will do. I think they’ll try adding garbage collection to Objective-C, but they won’t really commit to it and it will go largely unused, at least in the short-term. Long term, as garbage-collected Objective-C is slowly shaken out, I think it’ll start to creep into the mainstream thanks to mounting pressure to at least appear to match the level of abstraction provided by an increasingly mature CLR/WinFX platform (and Java).
No clear successor to Cocoa and Objective-C (with or without garbage collection) will be invented inside Apple. If suitable “pieces” do not appear in the market for Apple to adopt and assemble, then Mac OS X will stay with Cocoa and Objective-C until the external pressure to be better finally reaches crisis proportions.
I think Apple can postpone this crisis for a long time thanks to the quality of Objective-C and Cocoa, Apple’s small market share, and Mac OS X’s excellence in so many other areas. But eventually, the day will come when Cocoa and Objective-C just don’t cut it anymore. In the most optimistic scenario, that date could be a very long time from now indeed. I just hope Apple is considering the worst case, and perhaps reconsidering its ruthlessly product-driven strategy when it comes to the future of the Mac OS X application development environment.
Of course, predicting what Apple will do is a sucker’s bet. Who knows? Maybe they’ll announce that they’re moving everything to C++. (Boo! Did I scare you?) Hey, stranger things…
So, what about you, dear readers? What do you think Apple should do? I’ve heard nearly every suggestion imaginable at least once, but there’s no clear consensus. The comments section awaits below. I look forward to reading your thoughts.
This article originally appeared at Ars Technica. It is reproduced here with permission.