Article:		Cocoa Vs. Carbon?
Subject:		RE: I thought carbon would be the interim API ..
Date:		2001-05-23 13:12:21
From:		halliday
Response to: RE: I thought carbon would be the interim API ..
As to your question of "For example, why would the Finder be Carbon if Carbon was just an interim API?" The answer has already been given by Apple: To show developers that significant applications can actually be done in Carbon. So the Carbon Finder was "proof of concept" and has nothing to do with whether writing the Finder in Carbon is a good idea. (It also helped Apple work out some of the bugs and deficiencies in Carbon.) However, we can certainly see that Apple cannot continue a course where Cocoa and Carbon are on parallel development with all their own implementations. This is simply impractical, especially in the long term. This means that either Apple has to find some way to jettison one of these approaches (a highly undesirable prospect for Apple, I would say [though, personally, I would love to see Carbon go the way of the dinosaurs]), or they have to find some way to utilize the implementation in one framework from another (reuse). Unfortunately (for Apple, and for Cocoa developers), it is generally far easier to base an object oriented framework upon a sufficiently low level procedural one than it is to do the reverse (though you can wrap a very high level procedural framework upon a well factored object oriented one). This suggests that as things progress, we can expect to see either Cocoa based upon Carbon, or both based upon still lower level procedural frameworks (as is the case for much of the drawing and event handling).

Showing messages 1 through 3 of 3.

• RE: I thought carbon would be the interim API ..
  2001-05-23 14:01:33  James Duncan Davidson [Reply | View]
  
  
  I buy the argument that the Finder was written in Carbon in order to eat the Carbon dog food and to shake out the OS X implementation of Carbon. However, I still stand behind my statement that they wouldn't have engineered a critical piece of OS X in Carbon if it were an interim API and doomed to go away. We are probably going to be using this Finder for a while.
  
  I'm actually a bit bummed by the Finder being in Carbon and probably remaining that way for a while. It would make a lot of sense for Cocoa services to be exposed to items in the Finder. Quick encryption and signing of files comes to mind. Of course maybe Apple will provide a way for that to happen.
  
  As to Apple jettisoning one or the other: I don't see it happening. If anything, I think that the reuse under the covers of Carbon and Cocoa will only continue to improve.
  
• RE: I thought carbon would be the interim API ..
  2001-05-24 05:56:21  Daniel H. Steinberg [Reply | View]
  
  
  In the session on wrapping Mac OS X APIs in JavaBeans, the speech recognition and synthesis were shown sitting on top of Carbon. I think James' article and the resulting threads show that Apple needs to explain this dichotomy a little better. Check out the interview on the site with OMNI -- they were pretty critical of developers who created new apps in Carbon not Cocoa.
• RE: I thought carbon would be the interim API ..
  2001-05-24 15:28:43  James Duncan Davidson [Reply | View]
  
  
  You are absolutely right that the Carbon/Cocoa distinction needs to be explained differently. The view of the APIs on top of each other that I presented is simplistic, as is the view that they are parallel. There's actually a lot more going on than either of those views show. As I move through the conference I do find myself flipping between the two.
  
  As to OMNI being critical of Carbon application development, well, of course they should be. They've done a lot of amazing work in Cocoa and they deserve a lot of kudos. Please don't misunderstand my article as a vibrant support of Carbon. I'm a big proponent of Object-Oriented technologies and my current opinion is that new development for OS X should either be done in Cocoa or in Java Swing. But, knowing that Carbon's functionality is being used in both cases is good to know from the standpoint of understanding the system.