Cocoa Vs. Carbon?
Subject:   I thought carbon would be the interim API ..
Date:   2001-05-23 09:05:33
From:   zenarcade
As the subjects says . . . .Carbon would be the interim tool for the big corporations(Adobe, MS . .) to port their code quickly to OSX. As I recall, the reason why yellow_box never hit on was that it meant totall rewrite of application. And so, for not scaring away developers, carbon were "invented".

Maybe I am really way of here, but I thought that the main benefits from Cocoa was that any Cocoa application would have all the OSX technology "baked" in automatically ( like taking advantage of MP).


Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • James Duncan Davidson photo RE: I thought carbon would be the interim API ..
    2001-05-23 12:16:38  James Duncan Davidson | O'Reilly AuthorO'Reilly Blogger [View]

    I thought that as well for a while as a Java developer working primarily with UNIX and Windows while diving into the early Mac OS X DP releases. Bits and pieces of that thinking have been challenged for me as I've dug deeper and deeper into OS X and the APIs and how they go together. For example, why would the Finder be Carbon if Carbon was just an interim API? It was Monday's Frameworks talks at WWDC that really turned the lightbulb on as to how they go together.

    As far as taking advantage of all of OS X fundamental strengths, such as MP and preemptive threading, Carbon can use the system as well as Cocoa. Where Cocoa really shines is in all of the functionality that you get for free (such as spell checking), the ability to interface with other applications via Services, and a whole host of other really neat things enabled by the object-oriented nature of the framework.
    • RE: I thought carbon would be the interim API ..
      2001-05-23 13:12:21  halliday [View]

      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).
      • James Duncan Davidson photo RE: I thought carbon would be the interim API ..
        2001-05-23 14:01:33  James Duncan Davidson | O'Reilly AuthorO'Reilly Blogger [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.
        • Daniel H. Steinberg photo RE: I thought carbon would be the interim API ..
          2001-05-24 05:56:21  Daniel H. Steinberg | O'Reilly AuthorO'Reilly Blogger [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.
          • James Duncan Davidson photo RE: I thought carbon would be the interim API ..
            2001-05-24 15:28:43  James Duncan Davidson | O'Reilly AuthorO'Reilly Blogger [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.