Some Explanation Required, Cocoa and Carbon
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 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
Steve — Oct 07, 06 1960
You do realize everyone who reads this entry will check Google, right? But you didn't mention that you had to specify it exactly as "not a professional web developer" with quotes. I think the chances of someone actually legitimately searching for that and honestly believing it is pretty slim. Besides, your site design is great.
James Cunningham — Oct 07, 06 1961
http://www.google.com/search?ie=utf8&oe=utf8&q=%22a+professional+web+developer%22
John Gruber — Oct 07, 06 1962
http://www.oreilly.com/catalog/learncarbon/chapter/ch06.html
David Young — Oct 07, 06 1963
Now, remember of course that I'm a Cocoa developer to the Core (no pun intended), having come over to the Mac platform from OPENSTEP when I say: that is bullshit. Modern Carbon applications don't spin wildly calling GetNextEvent() anymore, and Cocoa event handling sits atop Carbon events. Check your stack backtrace the next time you set a breakpoint in some NSResponder method.
Unless you have the source code or some other inside information about iTunes, I would be careful make such an incorrect statement.
However, I do agree with Wil and probably 90% of other Cocoa developers: using Carbon royally sucks it, and the frameworks he called out are especially severe examples of this.
Jesper — Oct 07, 06 1964
That's exactly the point: We're not minding dipping into pure C from time to time, it's the part where we *write 80 lines of code to set one fucking parameter* that bugs us. It's the cryptic constants and OSTypes, the run-around-town documentation bouts and the extra lines of codes themselves.
CF code and Cocoa code can both pretty much be written by just looking at the documentation. Other C code in Mac OS X generally can't; you'll need to look at examples. This may have been the reality for a number of years now, but simply asking people to adjust means that they think the right thing to do is to never improve it, and I wonder if they're that stuck in their thinking.
And again, the above - CF and Cocoa is clear, other C APIs aren't - isn't generally because of design flaws, it's largely based on poor documentation. Look at *any* Carbon chunk and you'll see a list of functions, a list of structs and if you're very, very, lucky, a small exposition on how to put them together. Now look at a Cocoa class which often has a whole "guide" of its own, even if this has declined in recent years (NSLevelIndicator, NSSegmentedControl, NSDatePicker and NSTokenField).
Neither Carbon nor Cocoa lack thorough documentation of their own conventions and metaphors, but the general feeling is that Cocoa is way more well-documented than Carbon and in the general case produces way less code. You can wonder why.
Scott Stevenson — Oct 07, 06 1965
It doesn't actually bother me. It's sort of a running joke.
Matt Tavares — Oct 07, 06 1966
Carbon still has a myriad of crucial features that cocoa doesnt. I still use carbon events to create hotkeys and CGSEnableGlobalHotkeys to allow my hotkeys to be called anonymously.
I think when it comes down to it, alot of cocoa developers, at least in my experience, are very poor STL programmers. Most cocoa developers I have met seem to use just the "carbon is old and horrible" saying just to mask the fact that they don't know how to properly malloc structs, use hash tables, or research through the poor documentation to find out which type certain functions take.
I'll be the first to admit that carbon does take far more effort, and I am a cocoa programmer, but I still use carbon on a regular basis to impliment features which otherwise could not be done in cocoa.
Sorry if this sounds grammatically incorrect, i wrote this in a hurry.
flynn — Oct 07, 06 1967
I'm not sure what John's article is trying to add to the discussion besides belittling Wil in a "don't take him too seriously, he just wants to work less" way. As Wil states in his article, don't having a modern API makes all the difference to developers in a decision to use the stuff. If I can add LSM in a few days instead of a few weeks to my application, that's important. To me, my customers and Apple.
I don't need a Cocoa class for everything (In fact that would hurt more than help), but having a good documented, modern CoreSomething, free of Pascal structs isn't too much too ask for. In the end nobody cares if you are a tough geek assembling your toy out of a bazillion little pieces, while unrolling your loops, optimizing to assembler by hand, riding on a burning motorcycle. If you want to, please go ahead, shoot yourself in the foot. The rest of us however thinks it's crucial and not just "a nice to have" for the whole platform to use modern APIs.
Email — Oct 07, 06 1969
Scott Stevenson — Oct 07, 06 1970
I don't think it's an issue of masking, for the most part. I think many Cocoa programmers know how to malloc structs, research thin docs, and so on, but just don't think that's the way it needs to be. That's why we use Cocoa in the first place.
Ken — Oct 07, 06 1971
Really? Are Carbon Events then interchangaeble between NSEvents?
Matt Tavares — Oct 07, 06 1972
If daring fireball had comments, their would be 1000s before the day is over. Not to mention im pretty sure you can email him.
Dominik Wagner — Oct 08, 06 1974
The fact that programs like Word have idle cpu consumtion is just Horrible. The fact that it is carbon doesn't matter very much in this context. If you want to throw out another urban myth: Many Cocoa apps leak memory over time. Just run leaks on any Cocoa program you have used for some time.
Robert — Oct 08, 06 1976
I use Cocoa when I can, but am still a beginner much of the time.
I think everyone wants Supercard to program with, a Supercard that compiles, Cocoa goes half way there.
But the problem was that Supercard was always too slow, or too far behind the curve, or too gangly with add-ons.
Supercard was NEVER slow it was always outrageously fast but because it was not marketed as a language and there were no standards for scripting promoted, bad scripts always ruled the benchmarks.
It was ALWAYS way behind the curve, mainly because the features were driven by user requests, and everyone involved had a high level perspective who did not trust projections of how big the web would be.
So in the end they threw in a bunch of web add-ons to fix what was missing, of-course that makes it look like a tone of work to use.
I always thought the way to make Supercard a huge hit was to turn it into a real language, one that compiles, but as usual those who listened to me didn't really listen.
My suggestion was actually to build Supercard with C++ objects that could be configured by a runtime so that any runtime that the users configured would compile. This way any popular C++ compiler could be recommended to compile with and the company would just sell the framework.
And the vision is that the user would just work in Supercard as usual but what they built would compile to an app using only the required objects and classes.
And C++ programmers could meddle with the guts if they wanted, to their hearts content.
Then sell this level as a language, take a low level to highly perspective when building new stuff into it.
My guess is that when it comes to programming tools Apple ships whatever their employees give them, and Cocoa is a bit undermanned so is generally late compared to the others, and they keep on using carbon because they have many programmers that don't know cocoa. Well, also probably Adobe has very few programmers that really want to use Cocoa so they are twisting Apple's arm to make more carbon !!!
Its also very difficult to think low level and high level at the same time or the high level comes after the low level and it often takes a long time to get there.
I believe that the unseen real power in computing is the layering of systems that occurs without work or design effort, simply through circumstance. Frameworks of high level languages that run as layers over low level languages, which are truly open to programmers will receive a LOT of external scrutiny and help for free, and make Apple programmers jobs very easy, because external programmers will send them examples of what they want.
Or a single code base framework that has many runtimes that run on top of code to create the facade of the high level language, could allow everyone to work together and at whatever level they want.
Its all intended to created a world where everyone can participate, or at least way back in the early days THAT was the power in computing and programming, wasn't it !?!?!?!
Bret — Oct 09, 06 1978
After some quick spelunking in Activity Monitor and Shark, I think it's firing off a timer, that's doing some sort of refresh activity - I got a few hits on TimerVector and CFDictionaryGetValue as well as a bunch of various window related stuff...
Chris — Oct 09, 06 1990
1. I think the problem with Wil's post is that the thrust of his point (if you are correct in that it's just that he wants everything exposed in ObjC) is lost in his frothing at the mouth over how awful Carbon is. The tone of his post is way over the top.
2. To echo a previous poster: the Carbon event system underlies Cocoa's event handling (do a stack trace and see the variations on 'BlockNextEvent' -- those are Carbon event calls). Modern Carbon apps can be perfectly good citizens WRT CPU time, and Cocoa apps can be bad ones. iTunes is using a timer to do something requiring periodic action, the same way it would if it were a Cocoa app; it probably doesn't need to run a timer that often, but that's not Carbon's fault. My guess is it's something to do with the track name display.
BTW, on GarageBand's CPU usage: pro audio apps stream audio during the entire session, whether or not they're actually being asked to do something that involves recording or playback at any given moment. This is by design. Starting the audio hardware can be expensive, and you want to be ready to record immediately when the user presses the record button.
All of this said, I don't really see what all of the fuss is about. It's been made abundantly clear that Objective-C is the way of the future. Apple can't expose everything overnight in Objective-C; there's too much history and they don't have enough resources to do this and enormous tasks like the 64-bit transition simultaneously. Have some patience.
Bill Coleman — Oct 09, 06 1994
I also spent many years working on the Think Class Library, which started off in a pseudo-language that was basically C with Object Pascal extensions.
Frameworks like MacApp, TCL or PowerPlant certainly made doing Toolbox development palatable. Of course, they never had tools nearly as sophisticated as Interface Builder.
Apple has always had this problem of providing interfaces to satisfy everyone. Back in 1991, they were stating that if you weren't using object programming in the future, you wouldn't be able to program the Mac. But, since then, few APIs, other than a handful of Cocoa ones, have gotten the complete object-oriented wrapper.
Collecting something like QuickTime into a consistant, coherent object API (regardless of Objective-C, C++, Java, whatever) is a daunting task, one that Apple is never likely to complete.
We'll just have to be happy building, buying or borrowing object wrappers from others.
Scott Stevenson — Oct 09, 06 1995
The tone of his post is way over the top.
That's just his style. Sort of irreverant.
Modern Carbon apps can be perfectly good citizens WRT CPU time, and Cocoa apps can be bad ones.
Yup. I think I was just wrong on this. Although there must be some common factor, because Carbon apps seem much more likely to eat up cycles when idle. Maybe it's not Carbon's fault per se, but the result of code being written with certain thinking, and being brought forward across API changes.
Apple can't expose everything overnight in Objective-C
For me, the main question is why they're publishing new frameworks as anything but Objective-C, such as CoreVideo. Because of QuickTime. CF-style frameworks aren't all that bad, but they're still not Objective-C.
Uli Kusterer — Oct 11, 06 2037
1) Cocoa is newer than you think. NeXT did some substantial redesign work AFAIK. That's why we have those seemingly odd NXColor "compatibility methods" in NSCoder etc. SImilarly, the base classes used to have no prefixes way long ago...
2) On Robert's comment regarding Cocoa not being used as much as Carbon: Remember that Apple isn't a homogeneous company. There are different fractions inside Apple. Apparently, a lot of the CoreAudio people prefer doing their work in C++ (which actually makes sense, IMHO), while many other departments seem to have moved to Cocoa just fine. This is also the first time I've heard about the Cocoa team being understaffed (especially in comparison to the Carbon folks). Robert, could you elaborate on that?
3) Oh, and of course development takes time. So, the Cocoa stuff we only just start seeing now is what has been in development for the last few years. So, the lack of ObjC may just be the last remnants of the switch to OS X.
ElfNeedsFood — Oct 14, 06 2071
Umm, no, not really.
The "like" that you refer to include the thousands of MacOS developers who have real businesses to run, which includes actually shipping product (as opposed to, say, debating the pros and cons of languages and frameworks).
Something that seems to get missed in the lovefest that is Cocoaland is that without Carbon there wouldn't be a Mac OS X platform right now. Yes, that's right. No Mac OS X. The grand project would have been stillborn, like some pretty version of BeOS with the faithful and zealous arguing about the merits of their favourite frameworks and languages being used in products that nobody purchases for a platform that nobody buys.
As anyone who developed MacOS software in the Dark Years will know only too well, Apple have done a lot wrong over the years by their developers, but one of those evils isn't Carbon. A much greater evil would have been to arrogantly assume that the developer base has so much time and money on its hands that it could seamlessly transition to a new OS and new languages and tools (bye bye CW!!!) and languages and frameworks...
Scott Stevenson — Oct 14, 06 2074
Tell me how you really feel.
Ben — Oct 26, 06 2167
The Carbon API, based as it is in C, and thus highly friendly to C++, lives in the lingua franca universe of software development. Of course, that environment is as creaky now on the Mac as it is in the Win32 world, but the key point is that it's the comforting baseline; any developer worth their salt can figure out a C API and fold it into the methodology they're used to (which is probably C++).
As Apple tries to grab market share like it's 1979 all over again, more and more developers who've never touched a Mac before (like myself 6 months ago) will be looking for books and resources and samples to get into Mac programming, and the vast majority of them talk Cocoa, and those programmers come to a screeching halt, saying "What IS this thing with all the square brackets? You mean I have to learn a new language now? No, really, where's the underlying C API I can use? (or plug into my port from Windows)"
Because, let's face it: Objective-C is kind of a goofy language, and it's been kept alive since the early 90s in the (relative) backwater of Mac development, but it hasn't yet evolved much beyond its roots. It works at a markedly lower level of abstraction than Java or C#, which all the kids are learning these days ("get off my lawn!"). No namespaces (!), an unusual memory management model, and bizarre syntax, and for what?
Now: here's the part where I say that I have come to really love Objective-C in the time that I've been using it. I'm still not totally proficient at the design patterns, but the language, despite its syntactic goofiness, is the exact balance of low-level C pointers and high-level abstractions around strings, etc, that I have always wanted. I even like the retain/release/autorelease pattern a lot.
But ObjC and Cocoa are not yet ready for prime time. ObjC is stuck in the 90s, if not still the 80s. My understanding is that Leopard will see significant enhancements to the ObjC environment, which is a truly praiseworthy move. Garbage collection and namespaces are a bare minimum before ObjC as an environment has any hope of being a realistic choice for modern applications. Once Apple has sturdied the environment, then making new developers learn an entirely unfamiliar language will have real rewards for those developers, and Apple can legitimately push ObjC/Cocoa as the primary development environment for the Mac.
I'm looking forward to that day.
Scott Stevenson — Oct 26, 06 2171
Any competent C programmer can learn Objective-C in a few days. That's as true now as it was ten years ago. It's about to become easier in Leopard. As for C++, a lot of people seem to be using Objective-C++.
Although you may think it's a "goofy" language, it's also a key reason for Apple's incredible productivity. Things like Core Data would be much, much harder without the benefits that Objective-C's runtime provides.
I like John Randolf's suggestion of looking at the documentation for NSUndoManager (which intercepts invocations at runtime) and describe how you would go about implementing that in Java. A lot of that applies to Core Data now, too.
For what it's worth, I think Rails catches a lot of the same flack for the same reasons.
Ben — Oct 26, 06 2172
So my thought wasn't that Carbon as an environment was easier or better than Cocoa-- it's still a creaky, arcane C-based environment. Leave Carbon behind. The point is really more that Cocoa/ObjC are still catching up to the state of the art in modern application development. Until they are fully modern, Carbon has to be around and current for Apple to point to for everyone who writes huge apps and wants reassurance that their existing code and skills play nicely somehow in the Mac worldview.
I think Cocoa is great, and stuff like CoreData, bindings, and whatever's coming up in Leopard are all leapfrogging Cocoa to the forefront of development in general. As it matures, the argument can run like this: "Cocoa/ObjC is a simpler, more powerful, more rapid and easy to learn than *any other modern development framework on any platform*" This is a claim that Cocoa is nearing, but it won't be there till at least next Spring.
Note that I'm not claiming that Cocoa/ObjC isn't faster/easier than Carbon. I'm commenting on the original issue of Apple's perceived lukewarmness about betting the whole platform on Cocoa. Maybe my line of thinking is screwy, but it goes something like this: Cocoa+ObjC > Carbon, but Cocoa+ObjC < C#/Java in a few dealbreaker ways, therefore Cocoa+ObjC cannot be trumpeted as the one true development platform. When Cocoa+ObjC >= C#/Java, then Apple can make that claim, all effort can be put into Cocoa classes for everything, and people new to the platform will be pleasantly shocked by some of the power that's been there all along.
Scott Stevenson — Oct 26, 06 2173
Could you explain what you mean by this? Two friends of mine are doing .Net development and they both feel Microsoft is currently chasing Cocoa/Core Data instead of the other way around. Are you talking about languages or frameworks?
I fortunately don't have to muck around in that so I don't have first-hand experience, though I do look forward to the higher-level abstractions coming in Objective-C 2.0.
Stijn van der Schoor — Feb 25, 08 5570
Could anyone tell me where to find good Carbon tutorials for beginners. General tips or advice on how to start are also very welcome.
I've not been able to find anything up till now.
Advanced thanks
Stijn van der Schoor
Scott Stevenson — Feb 25, 08 5571
Your best bet is probably Learning Carbon by O'Reilly. You could also look at the CarbonDev site.
Also, keep in mind that the Carbon UI is now technically deprecated. It probably doesn't make sense to invest a lot of time in it now unless there's a specific reason you need it.
The Doctor — Mar 06, 08 5596
I would even go as far as to say that NEXTSTEP is basically a copy of MacApp.
Also MacApp is still maintained and developed (though not by Apple). It uses modern C++, it’s robust, it scales well, it supports Mac OS 9 through Leopard & Windows and its full source code is available to study & modify (which, personally, I find more useful than Apple’s documentation).
Customized web design — Dec 29, 09 7062