Volume Number: 17 (2001)
Issue Number: 12
Column Tag: Mac OS X

by Dan Wood, Alameda CA

The Tortoise and the Hare

Why Carbon Developers Should Start Learning Cocoa

We all know the fable about the tortoise and the hare. It can be interpreted many ways, but let’s say that it’s about the overconfident rabbit finding himself outpaced by the diligent tortoise.

Having returned from a week at WWDC, I am sad to report that there seems to be a tortoise-and-hare situation brewing in the Macintosh developer community.

In spite of the dominance of Windows and despite a recent economic slowdown, it was clear by looking at the crowds at WWDC that the Macintosh development community is alive and kicking. But let’s take a look at who is developing software for the Macintosh today. First off, you have the old-timers, the one who have been programming the Mac since the days of black/white screens and floppy disks. These guys can patch a trap in their sleep and understand the cosmic significance of Tech Note #31. But due to the acquisition of NeXT by Apple, there’s another group of developers that suddenly find themselves with a marketable skill set and a potential user base, and they were in force at the conference. (After all, the number of copies of Mac OS X sold to date has far surpassed the entire NeXT user base!) These weren’t the only kinds of developers at WWDC — after all, there were people who program in pure Java and are delighted to see a new platform for development and deployment, and there was a large WebObjects crowd as well. But on the desktop application development space, it was clear that there were two separate species — the Carbon-based life forms and the Cocoa-based life forms — and there wasn’t any camaraderie between them.

Two Frameworks

Apple has provided Mac OS X with two first-class frameworks for developing applications, Carbon and Cocoa. Carbon is an evolution of the procedural APIs for the Mac that date back to 1984. It’s the classic way of developing for the Mac, with a few twists to make programs run properly under Mac OS X as a first-class citizen. Cocoa is the object-oriented API for building Mac OS X that comes from OpenStep, which itself is descended from NeXTStep. And at WWDC, the Cocoa developers were outnumbered by the Carbon developers by a pretty big margin.

Perhaps there’s nothing inherently wrong with having two first-class APIs for programming a Macintosh. Nothing like this has ever succeeded before, though many (especially Apple) have tried. In general, an OS has always had a single dominant way of programming. Prior to Mac OS X, that dominant paradigm has been the Classic Macintosh Toolbox, programming in C++, using Metrowerks PowerPlant. So what’s the point of Apple trying to introduce a new framework (along with a new language, to boot) for development? Why is Apple trying to rock the boat? Are they just setting us developers up for a conflict?

Think Different

One thing that Apple has succeeded in doing over the last years has been surprising its detractors by creating amazing products. After the public had written off Apple for dead, here comes the iMac, the stylish G3 and G4, the drool-inducing Titanium PowerBook, killer apps such as iMovie and iTunes, and now an OS that pleases the crowds with Aqua and the geeks with its buzzword compliance and existing developers with its Carbon transition path

I’m going to go out on a limb by expressing the opinion that Cocoa is just such an amazing product, just one for developers. Trouble is, many Macintosh developers are going to have to “Think Different” if they are going to reap the benefits.

I feel qualified to express such an opinion because I straddle both worlds. I’ve been developing for the Mac since the screen was 512 pixels across. I’ve done my fair share of C++; I’ve written full-sized applications in PowerPlant, and I love MacsBug. But shortly after Apple acquired NeXT, I started learning Cocoa (or OpenStep or Yellow Box as it was called) and I started to, well, think different. I’ve since written a full-sized application in Cocoa. And frankly, I’m now spoiled: I don’t want to see another line of C++ again.

A Substantial Investment

Since I still have many friends and acquaintances in the “Carbon” camp, I am interested to hear what they think of Cocoa. It’s disheartening to hear how few of these folks express any desire to learn Cocoa. Some claim that they don’t like the syntax of Objective C. Others say that it’s too much of a learning curve. But I think that for the most part, it’s because long-time Mac developers have spent a long time investing in the Mac toolbox, and don’t want to see that expertise go to waste.

This makes a great deal of sense. After all, getting to know the intricacies of each manager in the Mac toolbox, along with the subtleties of C++ (a language that won’t stand still), learning and keeping up with PowerPlant, and tracking new APIs from Apple, is indeed a lot of effort over the years.

But perhaps a different approach would be to frame one’s expertise as owning a boat. Let’s say you like to race sailboats, and you have a boat that you bought 15 years ago. Every year you have to sink a substantial amount of money into maintaining it. One year, you have to overhaul the engine; another year there’s a leak to repair; perhaps the navigation system needs replacement. After fifteen years, you have a working boat, but you’ve sunk $100,000 into that boat over its lifetime. Somebody suggests you sell it and get a new boat, one that’s faster, more efficient, and less likely to need repair, but you’re going to resist it. After all, look at how much money you’ve spent on yours! And look at the new things you’ll have to learn to pilot and maintain the boat! That old boat will do just fine, thank you.

That kind of thinking may not be rational if you “do the math.” But it’s just as hard to let go of emotional investment as financial investment.

I view Cocoa as that new boat that traditional Mac developers are being offered. And it’s hard to let go of the years of honing your investment. And worst of all, I see a great community of Mac developers with “old boats” that are so immersed in their decision not to look at the new technology called Cocoa that they are going to find themselves the hares in the aforementioned fable.

Hare vs. Tortoise

Back to our Tortoise and Hare allegory. The tortoises, who have learned Cocoa — perhaps because they started out as NeXT developers, or perhaps because they had an open enough mind to try it out — have been quietly sneaking up with their shiny new boats made out of Cocoa. We haven’t quite reached this point yet, but I believe that the traditional Mac developers are going to find themselves “beaten” by the Cocoa developers — not in the sense of a one-on-one race, but in the marketplace. Why? Because once you have made the initial investment in learning Cocoa, the long and short of it is that it’s easier and faster to bring products to market.

Carbon’s advantages over Cocoa

Analogies are great, but they don’t work in real-world situations. And in the real world, there are lots of applications that need to be brought forward to Mac OS X. And Carbon is just the technology for that. Carbon means that you don’t have to throw away your code base and start over. Carbon means you can crank out new versions of your application in PowerPlant. Carbon means you get your application finished now instead of later. No learning of new languages or frameworks is required.

Cocoa’s advantages over Carbon

When you are starting to write any new application, however, you have to start designing and programming from ground zero. With Cocoa, ground zero is several floors above Carbon. Here is my take on why.

• Already object-oriented. Rather than needing to graft a framework such as PowerPlant over a procedural API (while still leaving all the underpinnings fully exposed), Cocoa is object-oriented at the most fundamental level.
• Heterogeneous data types. To represent a simple piece of data such as a string using C++ and PowerPlant and the Mac Toolbox, you may have to keep track of resources and pointers and handles, Pascal strings, null-terminated C strings, PowerPlant classes such as LStr255, C++ string objects, and so forth. Converting among all those types is half of your work! Cocoa has a string class called NSString. Other objects (such as dictionaries, numbers, booleans, colors, arbitrary data encapsulation, etc.) all have their own classes, and they all fit together in a modular fashion. You never have to parse through bits and bytes unless you’re reading a legacy data structure. Containers of objects contain other objects, enabling a complex structure can be read or written in a single line of code.
• Easier language than C++. Learning Java or learning Objective C shouldn’t be that difficult for an experienced developer. And the syntax is so much simpler that you can probably get by without a “language lawyer” on staff to help you understand the subtle intricacies of C++. To quote Tom Cargil from the C++ Journal, “If you think C++ is not overly complicated, just what is an abstract virtual base pure virtual private destructor, and when was the last time you needed one?”
• More Object-Oriented than C++. While C++ has the object-oriented properties of inheritance, polymorphism, and encapsulation, what is lacks is dynamism. With Objective-C (and, to some extent, Java), you can send an arbitrary message to an arbitrary object. The “fragile base class” problem of C++ does not exist in Objective C. Most of the classes in Cocoa take advantage of this, making it very easy build an application.
• No more “hookup” code. Even with the aid of a C++ framework like PowerPlant, much code needs to be written to access the user interface from the code (e.g. FindPaneByID()) and to dispatch user input to the code via switch() statements. In Cocoa, you hook up the code to the UI using Interface Builder. No code is written or generated, meaning significantly smaller programs.
• Flatter Class Hierarchy. Because of the dynamic nature of Objective C and the notion of delegation, the class hierarchy of Cocoa is extremely flat. Your applications rarely need to subclass Cocoa classes. The delegation model of Cocoa emphasizes cooperation between classes rather than extension of existing classes. By avoiding subclassing, your objects avoid having to know about the workings of their parent class.
• Gestalt. No, I’m not talking about an API for querying a Mac’s capabilities. All of the above reasons combined, somehow, make up an experience for the developer that is more than just their sum. Simple applications in Cocoa are just that — simple. Complex applications are possible and surprisingly manageable.

The Finish Line?

There is no real finish line; Cocoa and Carbon will continue to exist for some time. Each has their advantages, but Carbon is the winner when there are business reasons; Cocoa is the winner when there are technical reasons. As time goes on, the business advantages of Carbon will fade away, and the market for Cocoa programmers will be larger than the market for Carbon programmers. The developers that insist on defending their investment in Carbon avoid Cocoa when it comes time to build new projects may find that the Cocoa developers have beaten them to market. I hope that this doesn’t happen. If you are a carbon developer, start learning Cocoa in your spare time — Pick up the new Learning Cocoa book from O’Reilly and try it out. The smartest developers in the world are Mac developers — Imagine how much better off we will all be if they can leverage Cocoa.

Dan Wood is a long-time Macintosh developer who started learning about Mac OS X technologies immediately after Apple acquired NeXT. He has programmed for the Mac using Forth, Pascal, Scheme, 680x0 assembly, C, C++, Java, and Objective-C, using object frameworks such as Think Class Library, Metrowerks PowerPlant, Swing, and Cocoa. You can reach him at dwood@karelia.com.