May 28, 2003. Eric Blair refutes Andrew Stone’s braindead “Carbon is a dead API” theory - quite rightly so. In my experience, Stone Design’s products are much better at advertising OS X capabilities than they are at acting as examples of well-behaved, well-designed, uncluttered OS X applications, and there’s nothing wrong with that. But there is something wrong with shit-flinging other APIs. Most good Cocoa applications that have more than, say, four windows (and a good deal of those that don’t) utilize both Cocoa and Carbon, regardless of your preference for either framework’s window and event models.
However, the hilarity here is in the comments. The spirit of the comments were mostly right (and widely-spread) at the time. Switching to Intel was still the brain spook of a delusional John C. Dvorak, desperate for attention, ad click-throughs, heated opinions from trigger-happy Mac enthusiasts filling his Inbox in the triple digits, or all of the above. And if you ask me, the time wasn’t right for Apple to switch to Intel either - the G5 had more to give, emulation of PowerPC was yet untenable and Intel’s Core architecture (”New Generation Architecture”, separate from the Core family of chips) was the focus of napkin sketches in R&D, and not the company’s main interest.
Thusly, I present to you a couple of opinions that turned out to be fairly hilarious considering the success of the current transition:
“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.”
“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.” (Rosetta does support CFM, and Photoshop is unsurprisingly dog slow.)
A later voice of reason corrected the “Carbon won’t run” myth, saying:
“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.”
The article writer finishes off the thread by replying to the correction, noting (correctly, but not in direct response to the above, since the above noted that it’s possible, and the below notes that “yes, it’s possible, but it’s a pain in the ass, and I reckon you were arguing that it’s not a pain in the ass”):
“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.”