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 20 of 20.

• 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
• RE: I thought carbon would be the interim API ..
  2001-05-23 12:16:38  James Duncan Davidson | [Reply | 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 [Reply | 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).
• 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.

• 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
  
• Cocoa Vs. Carbon
  2001-05-23 12:00:41  James Duncan Davidson | [Reply | View]
  
  
  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.

• Cocoa Vs. Carbon
  2001-05-23 13:51:13  halliday [Reply | 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 | [Reply | 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.

• 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!
• Now Fixed...
  2001-05-24 15:29:33  James Duncan Davidson | [Reply | View]
  
  
  Thanks to the magic of the web, we've fixed up the article's technical flaw.

• 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.
  

• 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.
• It strange nobody mentioned it but carbon is the way to go for cross platform
  2001-05-25 13:10:42  dmag [Reply | View]
  
  
  I agree. Cross platform folks build their own Application frameworks, usually.
  
  Also, game programmers, often don't want all the application layer stuff. Folks developing new languages (or new implementations, or porting implementations) don't necessarily want to buy into ObjC. All this is good stuff, and Apple should welcome these folks to X.
  
  Since ObjC, which views objects as pretty coarse-grained, takes zero performance penalty for being built on top of a procedural layer, it seems like a good idea for Apple to keep a procedural layer around.
  
  (The fact that C++ supports fine grained objects well, but is weak on the course grained stuff (not dynamic enough) is what made ObjC++ such a good thing.)
  
  I think Carbon Events, which Cocoa seems to be built on top of, will survive, and some other key features, but a large portion of Carbon will slowly fade out as OS 9 disappears. It will be replaced with the Unix filesystem APIs, Mach memory management and thread packages, and the new procedural APIs, such as CoreGraphics and CoreAudio.
  
  Dan
  
  
• It strange nobody mentioned it but carbon is the way to go for cross platform
  2003-12-22 15:40:25  anonymous2 [Reply | View]
  
  
  Cocoa isn't built on Carbon Events. That was the entire point of some of the previous posts. Cocoa uses its own event handling code (look at the Apple docs that explain how the system fits together... you'll find that the event dispatch mechanism differs for Cocoa and Carbon).
  
  Apple *have* used Carbon to implement some of the Mac OS X Cocoa methods, but it isn't used from the ground up as your comment implies. They have also (helpfully) made it so that you can mix Cocoa and Carbon code in the same application. But that doesn't mean Cocoa is built on Carbon... it isn't; sure, some things use Carbon (NSMenu is a good example), but not everything does (which is why Cocoa apps behave subtly differently in many cases).
  
• It strange nobody mentioned it but carbon is the way to go for cross platform
  2001-05-28 01:19:47  laird [Reply | View]
  
  
  This comment is amusing, since Cocoa runs/ran across an amazing number of platforms. NeXT shipped the API's on 680x0, x86, SPARC, HP PA-RISC, etc. You may want to check out www.gnustep.org as well. Even better, the development tools allow you to build an application once and deploy it natively on every platform. Wonderful stuff. Apple ships Coca on numerous platforms as WebObjects, though (oddly) they don't allow application vendors to license them, so even though Carbon app's run across a half-dozen or so platforms, you can't really sell them that way. Still, it runs great on MacOS X, or anywhere WebObjects is installed. I sure wish that Apple would allow software vendows to license the runtime.
  
  
  
  
  
  
  
  
  
  
  
  Of course, the MacOS API's, including Carbon, are implemented in a completely Mac-hardware specific manner, so they'll never run on anything else (unless Apple throws $millions at porting it). So while it might be the case that procedural API's might be mappable ( though if you get into the details, the MacOS API's and Windows API's are quite different in almost every detail aside from a few cross-ported technologies (e.g. TrueType, QuickTime).
  
  So what it comes down to is that developers will have to pick between Carbon and Cocoa. And, having used both, Cocoa is clearly the right way to go unless you have an overwhelming pile of legacy code, and even then you're simply trading off a quick port now against a long, losing battle against competition using Cocoa and getting 10x your productivity. So any smart company, even if they're porting a legacy Mac app to Carbon had better be exploring a Cocoa port.

• 
  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.

• 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.
• There is no master plan
  2001-05-30 14:51:44  James Duncan Davidson | [Reply | View]
  
  
  Of course at the beginning of the Rhapsody project, the two APIs had nothing to do with each other. But I have to point out that Cocoa is no longer the cross platform OPENSTEP. It came from OPENSTEP, but has changed along the way. There is no way to take a Cocoa app (in contrast to an OPENSTEP app) and compile it to work on Windows or wherever else. And, in my opinion, if you want truely cross platform code, go for Java.
  
  Now, as to the benefits of OO vs. Proceedural -- I'm a huge propoent of OO. I have been writing nothing but OO apps for the last 6 years or so and wouldn't go back to writing proceedural apps. Theres no question that Cocoa has an advantage over Carbon -- a huge advantage. But, every good OO programmer should know what is underneath the system that they are using. And know that it is not an either-or decision. In fact, to me one of the real strengths of Cocoa is being able to drop down to Carbon if needed. Or all the way down to BSD.