Article:		Cocoa Vs. Carbon?
Subject:		Cocoa Vs. Carbon
Date:		2001-05-23 12:00:41
From:		duncan
Response to: Cocoa Vs. Carbon
When looking at the actual codebases inside, you are right is that Cocoa doesn't build on top of Carbon the same way that Powerplant builds on top of the Mac Toolbox. But, from the point of view of a developer looking at the APIs, especially a new developer to the platform, I think that looking at them as peers creates the Carbon vs. Cocoa discussions that we see. Looking at them as building on each other is a reinforcement of the view that object-oriented technologies build on procedural ones. As you help to illustrate when talking about how both APIs utilize Quartz, CoreFoundation, etc -- it is actually simplistic to look at the APIs either as peers or building on each other, but for better or worse, we sometimes need such simplistic views even though no one simple view is an accurate reflection of the situation. And the primary myth that I am trying to debunk in the article is that either Cocoa or Carbon are the one true API for OS X.

Showing messages 1 through 2 of 2.

• Cocoa Vs. Carbon
  2001-05-23 13:51:13  halliday [View]
  
  
  You state: "the primary myth that I am trying to debunk in the article is that either Cocoa or Carbon are the one true API for OS X."
  
  A, potentially, laudable goal, but not, entirely, true---at least from an historic perspective (thus, it's subject to change as things evolve).
  
  When you look at the history of this system, you see that BSD (and Mach services) and Cocoa (nee Yellow-Box, nee OpenStep) were there first. Java came next, and Carbon is the late comer (only added at the behest of developers that baulked at the idea of having to completely rewrite their old apps [highly understandable, to be sure]).
  
  Unfortunately, the weight of legacy APIs is strong, so, now that the legacy Carbon APIs are here they are likely to be here for a long time (besides, Apple doesn't want to rehash the issues that lead to the inclusion of Carbon---only if, and when, Apple sees that few significant apps use Carbon will it go away). So now Apple is having to deal with this situation.
  
  The best they can do (without throwing out the heavy weight Carbon based developers, or the significant, potential, competitive advantage of Cocoa) is to make the two peacefully coexist, without draining their development resources with a long term parallel development program.
  
  Their strategy will, almost certainly, be based upon code reuse (probably via a combination of basing Cocoa atop Carbon, when that makes sense, and factoring lower level code bases from both Carbon and Cocoa), developer migration (hence the sails pitch about Carbon for legacy and Cocoa for the future [but they'll carry Carbon forward so as not to anger the legacy developers]), and cross language tools (most notably the Objective-C++ compiler that was available in the NeXT era, but dropped early on with Apple---they are repenting this decision).
  
  Unfortunately, basing Cocoa on procedural APIs (whether Carbon, or a factored, lower level procedural framework) will, probably, slow development and technological advances. However, with tools like the Objective-C++ compiler, perhaps this procedural overhead can be minimized. (That's my hope, anyway.)
• Cocoa Vs. Carbon
  2001-05-23 14:24:20  James Duncan Davidson | [View]
  
  
  I definitely agree with you that from the historical perspective that Cocoa is the "Native" API. And after experiencing it (and having been a long time developer on the Java platform), I think that I would have really liked a Mac OS X without Carbon. But now that Carbon and Cocoa have been mixed, shaken and stirred into OS X, the historical perspective does not serve us that well. Just like the historical perspective of Java having been originally developed for small machines like interactive TV boxes doesn't do service to the current reality of Java in the enterprise.
  
  With that in mind, I'm pretty happy to see the two sets of APIs co-exist, share functionality under the cover, and even build on each other. And after seeing Scott Forstall talk about how they go together, I have good hope that they will be able to develop both without undue harm to either.