As you're learning about the Mac OS X frameworks, including Java, how do you see things fitting together?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 7 of 7.

• There is no master plan
  2001-05-28 01:26:24  laird [Reply | View]
  
  
  I'd like to point out a bit of an erronious assumption in this article. The two API's were never designed to have anything to do with each other. The reason that it's difficult for engineers to figure out the relationship between the two is that there isn't one. Yes, there are a few cases where Cocoa uses underlying Carbon services; this is a natural outgrowth of the fact that Cocoa runs across many operating systems (e.g. Windows), where it uses the native services, so when you run an OPENSTEP app on Windows, it'll use Windows print dialogs, etc.
  
  But back to the main point -- the two API's aren't layered, and there is no master plan fitting them together. Cocoa provides all of the high-level and low-level functions that Carbon does, and more, just in a object-oriented, portable manner while Carbon is procedural and non-portable. They're just two completely different programming models, driven purely by the fact that many companies and developers would rather maintain an existing code base than face a rewrite. So if you've got tons of legacy code, or hate learning, stick to Carbon.
  
  
  Cocoa is how a tiny company has produced a better web browser than a huge team at MS -- Cocoa apps are easily 10x easier to write than Carbon. I predict that Cocoa developers will out-perform Carbon developers, and that aside from a few markets where there's no real competition (i.e. people will always buy Windows, Photoshop, etc., no matter what any other company does), Cocoa-based products will beat Carbon in the marketplace, since the company will spend less money, produce higher quality software, and be more responsive to users' needs.
  
  So, as many companies have proven, you have to compete with your own products (i.e. use Cocoa) or your competition will do it for you.

• 
  2001-05-28 01:22:11  laird [Reply | View]
  
  
  I'd like to point out a bit of an erronious assumption in this article. The two API's were never designed to have anything to do with each other. The reason that it's difficult for engineers to figure out the relationship between the two is that there isn't one, other than that they both run on top of the same underlying OS. Yes, there are a few cases where Cocoa uses underlying Carbon services; this is a natural outgrowth of the fact that Cocoa runs across many operating systems (e.g. Windows), where it uses the native services, so when you run an OPENSTEP app on Windows, it'll use Windows print dialogs, etc.
  
  But back to the main point -- the two API's aren't layered, and there is no master plan to combine the two. Cocoa provides all of the low-level functions that Carbon does, and more. They're just two completely different programming models, driven purely by the fact that many companies and developers would rather maintain an existing code base than face a rewrite.
  
  Cocoa is how a tiny company has produced a better web browser than a huge team at MS -- Cocoa apps are easily 10x easier to write than Carbon. The only reason to use Carbon is because you've got too much legacy code to make a rewrite feasible, or you're too lazy to learn a new API. I predict that Cocoa developers will out-perform Carbon developers, and that aside from a few markets where there's no real competition, Cocoa-based products will beat Carbon in the marketplace, since the company will spend less money, produce higher quality software, and be more responsive to users' needs.

• It strange nobody mentioned it but carbon is the way to go for cross platform
  2001-05-25 02:34:14  eredler [Reply | View]
  
  
  Companies that wish to maintain a common code base for their Win/Mac application would find it quite hard with Cocoa.
  Since Carbon and Win32 are very close, conceptually, it is much easier to write such applications with Carbon.

• OO vs. Procedural just might not cut the whole cake
  2001-05-24 14:20:52  stefaanh [Reply | View]
  
  
  I remember the origins of Cocoa > Yellow Box > OPENSTEP > NeXTSTEP, and one of this kit's strengths was the abstraction of the operating system and the GUI. This might just still be valid and true. And while Java delivers too, the elegance and correctness of the Cocoa framework and the power of it's underlying Objc runtime system has no equivalent qua development power and time. Packing this with Darwin for i386 (686?) and your Cocoa's apps could eventually run virtually unmodified on a set of certified Intel boxes, or even (as some Yellow Box apps still do) on top of Windows 2000.
  

• Correction: Save dialogs are not Carbon, but Print Dialogs Are.
  2001-05-23 22:42:21  James Duncan Davidson | [Reply | View]
  
  
  An error in the article has been brought up to my attention. I should have said that the Print dialog is a piece of Carbon functionality. For whatever reasons while typing this article up in the back of the conference hall, I wrote "Save". Sorry about that!

• Cocoa Vs. Carbon
  2001-05-23 10:28:39  ali1 [Reply | View]
  
  
  Carbon and Cocoa have some interdependencies, but it is not the case one is built on the other; especially like MFC is built on Win32, or MacApp or Powerplant are built on the Mac Toolbox.
  
  There are instances where Cocoa uses higher levels of Carbon --- the menu bar and the print dialog are the two examples. But this is really an implementation detail from an application developer point of view, who is using the respective APIs of each framework. The example provided above --- that the save dialog in Cocoa is Carbon --- is actually not correct; Cocoa has its own dialogs for save/open, font, color, spelling... But, again, an implementation detail.
  
  The highest degree of sharing between Cocoa and Carbon is achieved by making the common services both need available at lower levels. That is why Carbon and Cocoa both appear as peers, in a layer above the ApplicationServices, CoreServices, and System boxes. These common services include APIs that are traditionally Carbon, traditionally Cocoa, and new --- examples are ATS, OpenGL, Quartz, CoreFoundation, LaunchServices... This approach allows high degree of code and data sharing, and interoperability. Where the two frameworks end up differing most is how they package and present these lower level APIs to the apps --- procedurally, or in an object-oriented fashion.
  
  
  From a developer point of view, I think the best way to think of both is as described in the article --- Carbon for existing apps, and apps that need to run on Mac OS 9 and X both; Cocoa for new apps. How much they interdepend is an implementation detail, as each has their own, independent APIs, and as Scott Forstall said, Apple is committed to carrying both forward as the native frameworks of Mac OS X.
  
  Ali
  

• I thought carbon would be the interim API ..
  2001-05-23 09:05:33  zenarcade [Reply | View]
  
  
  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).
  
  Tom