The other day, I mentioned my surprise at the lack of commentary on my Cocoa post. I was fully expecting to hear at least one person say that I totally didn’t get it, that Carbon was a dead technology, yadda yadda yadda. Well, one person preferred the analogy that my house was destined to be eaten by termites and thus it was better to rebuild it now than later.
I’m curious to know what the termites are in that analogy.
I saw a very interesting essay on Daring Fireball today. I particularly like this quote from John Gruber:
…in some cases, some people seem unwilling to concede that any criteria other than the ones they themselves deem important actually matter, or even exist.
Now, I’m not pointing any fingers at any specific people. I do believe that the choice to use Cocoa or Carbon is, loosely adapting from John, not a binary choice. It isn’t either-or, and neither option is always better than the other. I firmly believe that there are very valid reasons to use each ‘package’. Saying that ‘your house is going to collapse; you can’t avoid it, so go rebuild it now’ does two things.
- It denigrates all the work Apple has put into Carbon and continues to put into it.
- It ignores all the reasons I listed in my post for why we have heretofore continued to use Carbon.
Now, I don’t want to get too dogmatic in defense of Carbon, myself. After all, as I said in my first post and in the preceding paragraph, I believe there are good reasons to choose either platform. That’s why I’m curious to know why some folks are so dead-set on the idea that Cocoa is a magic bullet that can fix anything wrong with an app written in Carbon.
Let me know; we’ll chat about it.
9 replies on “Dogmatic Chocolate”
Well, maybe because carbon comes from Mac OS, and Cocoa from Mac OS X. And Mac OS X is the world’s most advanced operating system. For some people Carbon is something old that has no future.
*Why* does it have ‘no future’? Cocoa comes from NeXTStep originally, which is 20-ish years old. Not exactly a spring chicken…
Hi Schwieb – I just found your blog after seeing a reference to it on Rick Schaut’s. Great to see another blog focused on Mac development!
First let me suggest that as long as you require registration the number of comments you receive is always going to be dramatically less than it could be. I just decided to register and write this, but it was annoying to have to do so. There is a very real chance that between signing up, waiting for an email, filling out a form, re-finding the post I wanted to comment on, I would have gotten sidetracked and never finished the task. It’s a miracle I’m here right now 🙂
Another reason that people might be slow to reply to a Carbon/Cocoa debate is that it’s been hammered so long and hard in so many venues that many people know 1. there is no winner and 2. it turns into a flame fest.
That said, I read your Cocoa entry and I basically agree with your stance that it’s ridiculous to suggest a total rewrite. That said, I do think up-and-comers who start with Cocoa will have an easier time matching an app like Word’s feature set. Cocoa gives increased firepower to your competition.
Cocoa is old, but it builds its concepts at a higher level than Carbon. In many ways, with the merging of Cocoa and Carbon on OS X, Cocoa has become a wrapper of Carbon (or CoreFoundation, which became part of Carbon). The very fact that one can wrap the other speaks to the power it brings. What’s often overlooked is that Cocoa would be useless without Carbon (or Posix, or something else) filling in all the functionality cracks below the surface. On OS X, Carbon is part of the supporting cast that makes Cocoa possible. But for legacy application’s like Office, Photoshop, etc. that use Carbon exclusively and directly, they’re writing much of the “wrapper code” themselves. You’ve got your own document manager, you’re managing value change notifications, implementing an undo stack, etc.
If it’s not broken, don’t fix it. Right? But if it is broken in subtle ways that cause a disconnect between “the old way and the new way,” then you’re stuck fixing it in *your* wrapper instead of getting it for free (heh, never really) in Cocoa.
But worst of all for Carbon developers, it’s become clear that Apple favors Cocoa in many of it’s new technologies. Compare embedding a WebKit view into Cocoa vs. Carbon. Apple can’t afford to drop support outright for either framework. But as compromises continue to be made, I’m sure I know which framework will get treated as second-class. Fortunately it’s possible to embed Cocoa in a Carbon app, so you can pick and choose to some extent when it comes to that.
Thanks for your feedback, Daniel. I’ve turned off ‘require registration’ — I didn’t realize I had it on. Your assessment of Cocoa vs Carbon is spot-on. (Gee, have you been peeking in on our work over the past year? 🙂 )
The main thing to beware of in turning off require registration is that you may start to get bombarded by comment spam. Since you’re using WordPress you’re set up to easily take advantage of Akismet. It’s a life-saver. For example yesterday alone Akismet filtered 500 spam comments on my blog! I highly recommend it for if and when spam becomes a problem.
Yep, I’ve been running Akismet since day one.
Yikes. I didn’t realize my post would create so much animosity! I didn’t intend to demean or disrespect the efforts of MacBU. Office is a great application, and I use it everyday. I don’t even propose a change in its framework. You’ve all done an amazing job, seriously.
And if it’s any compensation, I really don’t know what the hell I’m talking about.
I’m a Windows developer, and I’ve never even touched Cocoa or Carbon. I’ve read about them and have a vague understanding of what they are, but I’ve never actually used either API; however, the sentiment I got on the net, and I’m sure this will be full of inconsistencies, is that Cocoa acts as the Windows equivalent of the managed, highly-object-oriented .NET framework, whereas Carbon parallels more of the MFCs and represent a direct communication with the OS’s GUI API. From the vantage point of creating an extensible, robust application, then, with some significant staying power, it would be wise, as I see it, to move to the higher level of programming. At first glance it’s a matter of style, but Jalkut touches upon something important: support. Carbon and Cocoa can only go as far as its platform, Mac OS X, will drive it.
MFC can still run on Windows. Everything’s functional, and it’s even faster, but its extensibility is far less developed than Microsoft’s CLR. Interoperability with C#, VB.NET, memory management, security, etc. — all of this is lost.
I’ll propose another analogy? You’ve built your house, but the community around you is gradually migrating to a larger city, featuring lavish skyscrapers and intricate monorail systems. Should you move? The cost of living in the city is greater, but you may find it easier to get around and, more importantly, that there are better places to go.
epong, I wasn’t intending to be mean or anything, so if I came across that way, I sincerely apologize.
I do like your second analogy. Cocoa definately has a lot to offer, and as Daniel notes, Apple is indeed creating some components that work best in Cocoa, such as WebKit views. I think the reality is some combination of your analogy and mine — there’s a lot of upside benefit to Cocoa apps, but there’s also a tremendous amount of pain involved in ditching Carbon. Plus, if you have some good frameworks written for Carbon (as we do) then Carbon still has a lot to offer itself.
In any case, thank you very much for your positive comments on Office and MacBU. I do appreciate an open dialog, as was my intent in bringing up Cocoa and Carbon in the first place. (No flame wars desired here!)
Nice Job. Great analogies and insight.
We will see less duplicated functionallity between the two frameworks in the future but at the same time more Hybrid apps, those “Carbon” applications calling Obj-C frameworks. More and more developers are looking at things more pragmatically as getting the best tool for each job weather through procedural Carbon APIs or OO Cocoa APIs.
Daniel, coming west to WWDC?