Shipley on Carbon vs. Cocoa

Oh God, ...

Only just came across Shipley's "Pimp my Code #12", and this is really too much smoke and mirrors. He complains that a low-level API is low-level, he claims that Carbon data structures were badly documented (the ones from pre-Jobs2 were documented very well, the ones that were added anew during the design of Carbon are pretty good, but of course they're not repeating conventions every Carbon programmer would know from the "Overview" book).

He claims that "Apple's definition of Carbon" included keychain and QuickTime ... well, not quite. They simply took the System 7-9 API dev web site, made one copy for the legacy docs, and then updated the contents for Carbon, so of course QT is in there, because it was already on that page before.

He compares the line counts of non-error-checked Cocoa code to Carbon code that uses two error-checking conventions (a "bail" label and a jump, as well as lots of "ifs" -- Good C programmers generally use the latter, and C++ programmers use exceptions). He pads the lines with comments and wrapping, no wonder he gets the line count for Carbon blown up. (oh, and no, it doesn't suffice to just get the error dictionary or NSError from one of the newer methods and ignore it to handle an error, you will actually have to do an "if", and in some cases even release it...but that was a commenter, not Wil's fault)

And it just goes on and on ...

Is he trying to stir general Carbon/Cocoa opinion in a direction that suits him? Well, good luck when he wakes up and notices that he can't do half the things he wants to do because Cocoa's NSSound class as of 10.4 can't even do volume control (bug already filed), and other cases where, as a commenter put it, "the classes fall over if you need more than basic functionality").

And as to the state of documentation: Have you ever tried to determine the valid run loop modes? All of them? Well good luck, because they're spread across three headers and only specified as NSStrings in NSRunLoop and NSApplication and NSWindow. I've literally filed hundreds of bugs against documentation omissions where it wasn't said what parameter could take what values in Cocoa. In Carbon, at worst you go to the legacy docs, which still document some stuff that got lost in the Carbon move.

As you may notice from my site, I use both Carbon and Cocoa. Not because I like one of them that much better, but out of necessity. You need a low-level API and a higher level, sometimes you need more control and performance, and sometimes you need quick deployment and automatic features.

Whatever Wil tells you, it's dang hard to optimize Cocoa code correctly, because it changes algorithms in mid-stride and thus makes it hard to find a reliable point to apply your improvements without just completely rolling your own -- and instead of completely rolling my own, I could just have improved my Carbon-based framework and be done with it, instead of figuring out what the hell this opaque piece of Cocoa is doing. I had to completely rewrite NSSpeechChannel and NSDirectoryEnumerator to give me one more bit of flexibility.

That's why Delicious Library is so slow, that is why it took Apple 3 revisions to get Mail.app to keep it from going brain-dead for five minutes when you quit and you had a mailbox with more than 1000 items, while MailSmith did it right from the start. That's why Apple can announce a new, faster text editor in Xcode again...

And cross-platform QuickTime in ObjC? Anyone notice that ObjC++ is still missing in anything but Apple's version of GCC? I think they're getting there now, but how would a C++-centric platform like Windows integrate QTKit without it? Make everyone wrap it in a C API? Wrap it in the old C QuickTime APIs?

Sorry, end of rant, but so much missing knowledge in one place just screamed for a reply.

Reader Comments: (RSS Feed)

itistoday writes: Nice post, no doubt Shipley's post was inspired by Apple's desire to move away from Carbon. He's an ObjC loon who's afraid of getting his feet wet in the low-level stuff and because of that makes for an easy target when he starts bitching about low-level APIs he has little experience with.

Harvey Swik writes: Could you provide a link to Wil's comments? Is this something recent? Sounds like something I read ~1yr ago.

Uli Kusterer replies: ★ @Harvey: Hmmm... you're right, this is "Pimp my Code 12", from last October. I'm intentionally not linking, but I guess this must have slipped into my inbox as new...

Or E-Mail Uli privately.