Some Explanation Required, Cocoa and Carbon

'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.

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.

Yes, the original Mac OS Toolbox APIs are a bit older than the original NextStep object system, but only by a few years.

Some Explanation Required, Cocoa and Carbon

Posted Oct 7, 2006 — 29 comments below Posted Oct 7, 2006 — 29 comments below

In " 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 thechance 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 Googlehas me as the top result for "not a professional web developer".But no. High road. High road.Before diving in, it's critical to understand is that a Cocoa programmer's beef with Carbon is its. 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. 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 theCarbon 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: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 aof 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.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 thatshould 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.So now that we know Carbon is a nebulous term, is it old or new technology? Daring Fireball says this:The date doesn't matter. Regardless of what Apple says for PR reasons, Carbondesigned to provide Mac Toolbox compatibility on Mac OS X. There's no other reason to put so much effort into a secondary application frameworkthey 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., 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.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: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, if not as dated in terms of when the code was written.