Some Explanation Required, Cocoa and CarbonIn "Some Assembly Required" (a lot of layers to that title) John Gruber responds to Wil Shipley's article about the fact that Apple is still publishing procedural frameworks. The short version is that Shipley doesn't like this and Gruber says it's not all as bad as Shipley makes it sound.
Now this would be the perfect chance for me to lob one back at Daring Fireball for that incident back at the beginning of the year, but I won't. Even though Google still has me as the top result for "not a professional web developer".
But no. High road. High road.
What is Carbon?
Before diving in, it's critical to understand is that a Cocoa programmer's beef with Carbon is its design. Carbon code is written using lower-level procedural C, often involving calling functions with long lists of unnamed parameters.
It's not all bad because you use opaque "objects" like CFStrings instead of char buffers, but it's still the C language. You lose some basic Cocoa concepts like runtime evaluation and key-value coding. None of this is in dispute, by the way.
The problem is that defense of Carbon often comes in the form of citing the functionality Carbon offers, not its design. So the two sides end up having two unrelated arguments. I ask for a four-door vehicle to drive around town and you deliver me a army humvee which runs on diesel. Yes, technically that does have four doors, but it's not the sort of package I had in mind.
Daring Fireball says:
'Carbon' is humongous; it’s an umbrella label for a huge number of APIs. Some of these APIs do exist for compatibility with the old Mac OS; but some of them are brand new and only exist on Mac OS X.
On paper, this is true. The real world picture is a little fuzzier. Most Mac users that know the term Carbon think of it as a kind of application. iTunes is Carbon, iWeb is Cocoa. That sort of thing. You can mix and match, but an app is ultimately based in one key framework.
Developers are split. Some think of Carbon as the high-level application classes like HIView, others think of it as all of that, plus any of the lower-level procedural frameworks, often prefixed with "Core," such as Core Foundation.
But wait, there's more.
Not everything called "Core" is included in the Carbon umbrella framework, and the prefix core "Core" doesn't even necessarily mean procedural. CoreImage is an Objective-C (Cocoa-centric) framework, even though it sits right beside CoreVideo which is a procedural, CF-style framework. CoreData has the "Core" prefix but is exposed as Objective-C, and is even included in Cocoa.h.
Lost yet? Yup, so are we.
Wil Shipley's point is that everything should ultimately be exposed as Objective-C. QuickTime is already heading in this direction with QTKit. So maybe his concern isn't so much "Carbon" as it is Apple publishing procedural frameworks.
Is Carbon Old or New?
So now that we know Carbon is a nebulous term, is it old or new technology? Daring Fireball says this:
For one thing, [Wil Shipley] starts by calling Carbon a 'compatibility library' for 'older applications', and Cocoa a 'new application environment', even though both date from the 1980s.
The date doesn't matter. Regardless of what Apple says for PR reasons, Carbon was designed to provide Mac Toolbox compatibility on Mac OS X. There's no other reason to put so much effort into a secondary application framework unless they intended to replace Cocoa, and that's clearly that's not the case.
Carbon came about because Microsoft, Adobe and the like weren't going to budge. By design, Carbon stretched itself between Mac OS 9 and Mac OS X. This shows up in both API and the behavior.
On the behavior side, look at event processing. An idle Cocoa app is generally just that: idle. An idle Carbon app often will just sit there and constantly poll for events. You can see this right now with iTunes. It's less of an issue as machines get faster and faster, but it's still there.
(Update: It sounds like Carbon apps eating up cycles even when idle isn't necessarily event polling. If someone could point out what it actually is, please speak up.)
Wil Shipley describes the syntax side really well. In short, Carbon generally makes you write a lot more code that's a lot harder to read.
Back to Daring Fireball:
Yes, the original Mac OS Toolbox APIs are a bit older than the original NextStep object system, but only by a few years.
The years are pretty close but the thinking is miles apart. NeXT jumped on the object-oriented bandwagon. It took PowerPlant for that to happen on the Mac side. So maybe the way to say it is that Carbon uses much more dated concepts, if not as dated in terms of when the code was written.
(As a side note, I'm amazed and perplexed that the second result for 'not a professional web developer' is a direct link to John Gruber's comment on this site. How in the world does Google know that his is the most important comment, particularly given I only added direct links to comments about a month ago?)
Some Explanation Required, Cocoa and Carbon
Posted Oct 7, 2006 — 29 comments below
Posted Oct 7, 2006 — 29 comments below