Stone Cold

Wednesday, May 28th, 2003 @ 8:32 pm | Mac

Andrew Stone’s at it again with his pro-Cocoa/anti-Carbon rants. This time, he’s claiming long-time Mac developers are shipping “old” code filled with “old” bugs instead of being sensible and rewriting years of stable code in Cocoa.

For some truly in-depth comments on this topic, check out John Gruber’s Stoned. This particular entry was written on April 28th, shortly after the initial FontSight press release was issued, and does a very incredible job of debunking Stone’s claims.

Before I say too much, I want to disclose the fact that I am employed as a computer programmer and the Carbon framework is one of the frameworks we use in our products. When I’m working on my projects outside of the office, though, I also use the Cocoa framework. I’m not going to say much more about my employer because I try to keep my work separate from this web site.

Here’s a choice quote from Stone’s entry:

Folks, I’ve been slaving away for the last 15 years to bring the object technology of NeXT (now called Cocoa) to the Macintosh Masses. In 1997, Gil Amelio told all the legacy Mac developers this was the future, and they should begin an effort to rewrite their code in Cocoa (then called Rhapsody).

They decided to ignore him and instead demanded a way for the new Mac OS X to run the old macos 9 code.

Gee, I wonder why Andrew Stone would want to bring Cocoa support to the Mac. I have difficulty thinking it purely so the “Macintosh Masses” could experience the nirvana that is Cocoa. In fact, I think the relative of the markets for NeXT software and Macintosh software may have had something to do with it. I don’t have a problem with that — getting the Stone Design software library into the Mac marketplace without having to rewrite the code from scratch was probably very good for Andrew Stone’s business.

From this point of view, Cocoa is to NeXT developers what Carbon is to Classic Macintosh developers. In Stone’s world, though, it’s wrong for Classic Macintosh developers to want the same thing that Stone wanted — a way to develop software for OS X without throwing away years of code, experience, time, and money.

Considering the subject, it’s shouldn’t come as any surprise that Stone disparages anything Mac-related that came before OS X. How come it’s “Mac OS X” but “macos 9?” Why is “Cocoa” capitalized but “carbon” not?

Stone also calls “carbon apps” “quick ports” without bothering to check out the release dates for the various Carbon applications. BBEdit came out very quickly. However, it’s also one of the best-written applications on either OS 9 or OS X and Bare Bones employs some very talented developers. Microsoft Office, however, came out much later — many people would argue there was nothing “quick” about it.

In all likelihood, this is the last of Andrew Stone’s weblog entries I will ever read. I’m tired of listening to him insult and belittle long-time Mac developers who have done and are doing much more for the platform than Andrew Stone has ever done. Seriously, Andrew, show a little respect.

In closing, I’m going to paraphrase Stone’s closing statement from the aforementioned post:

I cannot be an apologist for long-time cocoa developers, so please don’t expect me to blindly accept the insulting statements from entrenched cocoa developers who seem to think OS X exists solely to save their companies from the obscurities of the NeXT world.

17 Responses to “Stone Cold”

  1. Buzz Andersen Says:

    Yeah, it’s pretty funny that he mentions the iApps and then trumpets the start time of Cocoa apps compared to Carbon apps. Has he opened iPhoto lately? Or even iCal? Apple continues to bring new technologies (Rendezvous, Disc Burning API, etc.) to Carbon, so it’s clearly still a first class citizen of the OS X world. My only complaint, as I’ve said on my own weblog, is the disparity that often exists between what’s implemented in Carbon and what’s implemented in Cocoa. IMHO, Carbon File Manager is way better than NSFileManager–not as easy to use, but a lot more powerful.

  2. NSLog(); Says:

    A Stone’s Throw

    Those who live in glass houses shouldn’t throw an Andrew Stone: In all likelihood, this is the last of Andrew Stones weblog entries I will…

  3. Eric Says:

    I completely agree with you, Buzz. I’m still shocked at the condition of QuickTime when it comes to Cocoa. Likewise, I believe most, if not all, of CoreAudio is implemented in Carbon. Every so often somebody will post a question to the CoreAudio dev list along the lines of “How do I use CoreAudio with Cocoa,” “Where is the Cocoa CoreAudio interface,” or “Does anybody have a Cocoa wrapper for CoreAudio function blah?”

    Simply put, both frameworks need work.

  4. Michael Tsai's Weblog Says:

    Stone Cold

    Go Eric. The fact of the matter is that companies like Unsanity and St. Clair Software go the extra mile to make their patches work with both Carbon and Cocoa. If Stone doesn’t want to do that, it’s his choice, but he should stop spreading…

  5. Andrew Duncan Says:

    I’m no Cocoa bigot, but consider…

    How likely is it that, if Apple release a version of OS X for Intel chips, Carbon will be available? Not very, IMHO. So, if you don’t mind if your app only runs on PowerPC, or you don’t want to see the size of your market increase markedly, go ahead, use Carbon.

    I wouldn’t advise anyone creating a new application to use Carbon. If, however, like Adobe, you have a large existing investment in Carbon frameworks, and time-to-market is important, go ahead and use Carbon.

  6. LKM Says:

    How likely is it that, if Apple release a version of OS X for Intel chips, Carbon will be available? Not very, IMHO.

    That must be one of the absolutely weirdest things I’ve ever read. It’s wrong on so many levels… Here are two of them:

    1) Apple won’t port Mac OS X to Intel chips. This whole Intel stuff doesn’t even qualify as a rumor anymore, it’s nothing but a joke. And a bad one at that. 2) Even if Apple did, in some parallel universe, port Mac OS X to Intel, it would better make damn sure that Carbon works on Intel, too. If it didn’t, the “new” Mac OS X would be born dead. No Photoshop, Illustrator or Quark? No market.

  7. Nat Irons Says:

    How likely is it that, if Apple release a version of OS X for Intel chips, Carbon will be available? Not very, IMHO. So, if you don?t mind if your app only runs on PowerPC, or you don?t want to see the size of your market increase markedly, go ahead, use Carbon.

    You’ve arrived at one of the several fine reasons there will never be a Mac OS X on Intel — it’d never see Photoshop, Office, Quark, or InDesign.

    You’re kidding yourself if you think anybody’s going to port those bad boys. As expensive as the Carbon transition was, porting without Carbon was never viable. Asking them do it without Carbon now, before the shift to Carbon has even begun to pay for itself, is a laugher.

    Carbon is a transition strategy only if Apple wants to transition to going out of business.

  8. BBEdit Suckage Says:

    Come on, it took BBEdit six versions to get basic, nonextensible syntax highlighting. You’ve got to find a better example than that. Cocoa people aren’t going to understand BBEdit.

    And, Nat et al: There’s no portability problem with Carbon that does not also exist for Cocoa. Carbon is not a 68k emulator and does not contain one. Carbon apps are usually written entirely in a high-level language. The Carbon framework itself is written entirely in C and C++ and was derived from Mac OS 9 via Copland via Star Trek. It has been ported to x86 before and would be ported again if Apple wanted to do OS X for x86. Too much of the core technology of OS X is built on Carbon, whether Stoner likes it or not.

  9. Sren Kuklau Says:

    Sigh. And I thought the last thing we needed was a Mac OS X on Intel debate.

    “How likely is it that, if Apple release a version of OS X for Intel chips, Carbon will be available?”

    It’s not even possible. Most Carbon apps use the Code Fragment Manager, which makes heavy use of direct PPC calls. Because Mac OS X doesn’t allow such direct calls any longer (in contrast to Mac OS 9), Carbon/CFM apps are slower than Carbon/Mach-O apps (those that call the Mac OS X Mach-based kernel instead). Mozilla builds with Carbon/Mach-O were about 30% faster than Mozilla builds with Carbon/CFM.

    Not only that, but CFM on x86 would mean absolute emulation of lots of system calls. Do you want an emulated Photoshop? I think it’s slow enough when it’s “half-native”, as it is now.

    Besides, Mac OS X on x86 is not going to happen, if only because x86 is a dying architecture (ever heard of AMD64 and IA-64?).

    “There?s no portability problem with Carbon that does not also exist for Cocoa.”

    Yes there is, CFM. Cocoa builds are always Mach-O; Carbon builds (when ported from Mac OS 9) cannot be, because Mac OS 9 doesn’t support Mach-O for obvious reasons.

  10. Eric Says:

    There’s nothing that stops a Carbon developer from changing their build process from CFM to Mach-O. I believe Microsoft did this for Office X, which is OS X only. Changing build settings in this way is vastly different from switching development frameworks over to Cocoa.

    Mac on Intel’s not going to happen. It looks like IBM’s developed a higher performance PowerPC chip (the 970) that will simultaneously boost the speed of Apple’s systems and not require radical changes to existing programs.

  11. Rosyna Says:

    No, Office for OS X is still CFM. GUI applications that are Mach O on OS X MUST be packaged. Office is not and runs with LaunchCFMApp. CFM is much faster when calling it’s own functions than MachO and I would not consider Mozilla a good example. iTunes lost about 10%+ it’s speed in iTunes 2 to 3 when it became Mach-O

  12. Eric Says:

    Ah. I hadn’t realized that CFM required switching to packaged apps, though I’m not surprised.

    My point still stands — you can switch Carbon apps to Mach-O so CFM isn’t a hard and fast barrier tying all Carbon apps to PowerPC.

    Like I and others have said, though, it looks like this is a moot point. Apple’s not switching to Intel. Carbon’s not going away.

  13. BBEdit Rules Says:

    Come on, it took BBEdit six versions to get basic, nonextensible syntax highlighting. You’ve got to find a better example than that. Cocoa people aren’t going to understand BBEdit.

    BBEdit has had syntax coloring since at least version 4. If you don’t mind a little programming, you can add your own syntax modules. There are already various third-party modules available, such as SQL.

  14. Eric Blair Says:

    Yeah, I don’t know where that original BBEdit comment came from. Somehow, I doubt it’s Rich Siegel, as the email address would seem to indicate.

    However, I don’t like deleting comments, so it stayed posted.

  15. kokorozashi Says:

    This comments list is is almost as full of hooey as Stone’s.

    Carbon would port to Intel just fine. It’s C and C++ code. It’ll recompile just as nicely as Cocoa will. And it had better, because Cocoa depends on Carbon.

    That doesn’t mean there will ever be Mac OS for Intel. Apple sells computers with design features which command high margin. Show me a way for Apple to make high margin on Intel-based computers and then we can talk about the hurdle of recompiling all the apps so that Apple can make computers which… work exactly the same as far as users are concerned. Why were we pining for this again?

    No, it’s not difficult for a ported Carbon app to move from CFM to Mach-O. I’d be surprised, though, if Apple didn’t take the opportunity to move to a new executable file format for this mythical Intel machine. Everyone but the one Mach-O engineer (is he still hanging on?) agrees Mach-O is crap.

    And no, Carbon’s lineage is not Copland or Star Trek. It’s QuickTime, if anything, but in truth that was just for the initial demo, and then pretty much everything got rewritten.

    Where people get these ideas is beyond me. Oh yeah, I forgot: They make them up to feel well-informed.

  16. Eric Blair Says:


    I stopped believing in the “it will just recompile option” many hours of unpaid overtime ago. There’s almost always going to be some amount of work necessary for supporting a new architecture. Maybe the code will recompile fine, but you’ll need to optimize certain operations for the new processor because the old instructions now run X times slower. There’s always going to be something.

    As for the Copland/Star Trek fellow, I wouldn’t put a whole lot of stock into what he says. I’m still not entirely sure what point he’s trying to make and I’ve had 2+ months to look at the damn thing. 😉

  17. Lola Lee Says:

    Now I finally realize why I was seeing FontSight only in some programs. Argh – you’re right, Stone’s attitude is very backward. Soon as FontCard comes out, I’m going for it.