Cocoa v. Carbon Applications

Posted:
in Mac Software edited January 2014
Other than the good looks of Cocoa applications, do they have any significant advantages over Carbon applications?



Also, are all the applications that come with Mac OS X (iCal, Mail, Finder, iPhoto, etc.) Cocoa or are some of them Carbon?



Just wondering... thanks.
«1

Comments

  • Reply 1 of 21
    Finder and iTunes are Carbon
  • Reply 2 of 21
    dfilerdfiler Posts: 3,420member
    Step One: Dig up horse

    Step Two: Commence beating

    Step Three: There is no step three...
  • Reply 3 of 21
    buonrottobuonrotto Posts: 6,368member
    Cocoa's main advantages are behind the scenes, benefits for the developer. My basic understanding is that Cocoa does more things automatically, requiring the developer to do less work on the mundane parts and upkeep of their app. This isn't always desired though, so Carbon has its own advantages in that sense. That's sort of the trade-off in a nutshell: Carbon requires some more effort but allows some more control and Cocoa takes some stuff out of your hands (as a developer) but requires less effort and upkeep.



    Cocoa and Carbon can and *should* pretty much have the same look and feel to the user. However, because Carbon is rooted in the old Mac OS and allows for some fallback with legacy technology (like QuickDraw) so that, some frankly lazy developers write "bad Carbon ports" of their apps for OS X and they look like crap. Apple allowed this so apps wouldn't break outright in the transition to OS X, but they're pushing for everyone to get off those old technologies in Tiger, and are sending out signals that this legacy tech will start to be dropped sooner than later (but not in Tiger).



    Cocoa is rooted in the old OpenStep OS, so some details like some text handling features, differ from Carbon's features. Apple keeps pushing this stuff closer together and trying to eliminate these differences.
  • Reply 4 of 21
    kickahakickaha Posts: 8,760member
    Quote:

    Originally posted by BuonRotto

    Cocoa and Carbon can and *should* pretty much have the same look and feel to the user. However, because Carbon is rooted in the old Mac OS and allows for some fallback with legacy technology (like QuickDraw) so that, some frankly lazy developers write "bad Carbon ports" of their apps for OS X and they look like crap. Apple allowed this so apps wouldn't break outright in the transition to OS X, but they're pushing for everyone to get off those old technologies in Tiger, and are sending out signals that this legacy tech will start to be dropped sooner than later (but not in Tiger).



    QuickDraw at least won't be *dropped* in Tiger, but it is *deprecated*. All those neat new funky graphics things in CoreImage? Not a single one is being moved to QuickDraw. QD is abandoned, as of this moment. Any developer using it needs to get on the ball now, because they are going to be left in the dust by their competitors.
  • Reply 5 of 21
    buonrottobuonrotto Posts: 6,368member
    That's what I meant, don't know if it was clear: old QD tech isn't eliminated from Tiger, but it is clearly only sticking around just in case. Apple in that State of the Union for Graphics presentation said something to the effect of, "get your code over to Quartz (which Cocoa uses all the time) now, because Tiger is the beginning of the end for QD."
  • Reply 6 of 21
    pbg4 dudepbg4 dude Posts: 1,611member
    Apple really needs to make all of QuickTime accessible through Cocoa before Carbon is completely killed. I believe CoreAudio/MIDI can do everything I need but CA/CM is so confusing and much of it is scarcely documented compared to doing the same functions in QT.
  • Reply 7 of 21
    buonrottobuonrotto Posts: 6,368member
    Seems like that's the path for QT. The way it was presented in that graphics State of the Union presentation, QT seems like higher-level access to CA/CI (CM?) for most developer work, while you can still go down to them or down to even OpenGL directly if you need to in specific cases. To a lay person like me anyway, it looked like they're ripping out the guts of QT and even reworking the top end of it. It's almost like the only piece that's remaining is the file format support.
  • Reply 8 of 21
    amorphamorph Posts: 7,112member
    Quote:

    Originally posted by PBG4 Dude

    Apple really needs to make all of QuickTime accessible through Cocoa before Carbon is completely killed. I believe CoreAudio/MIDI can do everything I need but CA/CM is so confusing and much of it is scarcely documented compared to doing the same functions in QT.



    Where do you get the idea that Carbon will be killed? It's still being developed!



    The stuff that's getting killed is old cruft like QuickDraw; more to the point, QuickTime is finally getting slimmed down instead of being a huge, self-contained black box. That will allow all the finicky low-level calls to be cleaned out of the API (because the low-level libraries have APIs too—if you want CoreAudio, call into CoreAudio).
  • Reply 9 of 21
    Quote:

    Originally posted by PBG4 Dude

    Apple really needs to make all of QuickTime accessible through Cocoa before Carbon is completely killed. I believe CoreAudio/MIDI can do everything I need but CA/CM is so confusing and much of it is scarcely documented compared to doing the same functions in QT.



    Doesn't QT 6.6 in Tiger have a new framework for QT?
  • Reply 10 of 21
    costiquecostique Posts: 1,084member
    Quote:

    Originally posted by Amorph

    Where do you get the idea that Carbon will be killed? It's still being developed!



    And I suspect that Carbon is being developed even more massively than Cocoa. In fact, in many respects Cocoa is a poor cousin to Carbon.
  • Reply 11 of 21
    buonrottobuonrotto Posts: 6,368member
    I hope you don't mean that Cocoa is a second class citizen in the OS. 'Cos that sure ain't true either.
  • Reply 12 of 21
    kickahakickaha Posts: 8,760member
    Since your comment not only contradicts the publicly available evidence, but also Apple's official *AND* unofficial positions, costique, I'm going to have to ask what evidence you have to back that up.
  • Reply 13 of 21
    buonrottobuonrotto Posts: 6,368member
    I suppose it depends on your perspective. My understanding is that Cocoa takes care of the more mundane stuff in your app, leaving you, the developer, to take care of what you consider the more important stuff. But Carbon may give a developer some more control over all aspects of the app's creation, so while it's maybe more work, it can mean more flexibility. I mean, is there a tradeoff to be accounted for here?
  • Reply 14 of 21
    kickahakickaha Posts: 8,760member
    One could look at it that way, I suppose, but a Cocoahead is going to counter that one has darned near the same amount of fine control in Cocoa (if not the same level), once one groks the framework.



    Carbon is much more straightforward for someone who is used to procedural programming, and Cocoa looks utterly bizarre. To an OO junkie though, like myself, Cocoa makes perfect sense. The control is there, it's just not exposed until you choose to take advantage of it, while with Carbon you have to deal with it up front.



    Carbon may indeed be undergoing more development than Cocoa. Refurbishing a junker is usually more work than starting with a collector's beloved vehicle.



    Seriously, Carbon needed a heck of a lot of work to get the same functionality that Cocoa takes for granted in some areas, and in others, Cocoa apps have to defer to Carbon calls. Like, say, QuickTime. (grr)
  • Reply 15 of 21
    buonrottobuonrotto Posts: 6,368member
    There's also the whole issue of how one framework creates different behaviors than the other, usually in the details. For example, Cocoa text has some different behavior from whatever most Carbon apps use. I mentioned elsewhere today that Stone Design's Create got a marginal review from MacWorld back in 2001 because its text handling was non-standard from the reviewer's point of view, the reviewer coming from OS 9 and OS X being in its infancy. But Create's text handling is simply Cocoa's text handling, no funny exceptions made.



    Since then, some text features in Cocoa have changed to act more like the old Mac OS way, but for the most part, Apple is promoting whatever text framework these Cocoa developers used to all developers, and old conventions are giving way to this way of doing things. That Carbon may be getting more work may, as Kickaha said, be a reflection of this shift towards Cocoa/OpenStep/OO conventions.
  • Reply 16 of 21
    costiquecostique Posts: 1,084member
    Quote:

    Originally posted by Kickaha

    Since your comment not only contradicts the publicly available evidence, but also Apple's official *AND* unofficial positions, costique, I'm going to have to ask what evidence you have to back that up.



    Hmm, really? Not to delve into political reasons, I'll just note that Apple is paying close attention to the needs of big 3rd party developers. Who are they? Mainly audio/video production, graphics/prepress and the like. Most of them don't work with ObjC for reasons of their own, mainly because they use PowerPlant or have their own frameworks in C/C++, obsessed with performance or simply not willing to invest in learning ObjC - it doesn't matter. They seem to constitute a majority of ADC Select and Premier members. And they are pushing Carbon just because they depend on it. And Apple cannot ignore them and tries to perfect Carbon as much as possible.



    What we have right now is that if you want to do something advanced (receive more event notifications in your run loop, convert text to an uncommon encoding, compose non-trivial AppleEvents, utilize CoreAudio, modify resource forks, access HFS features, and so on, and so forth) you have to use Carbon. Carbon is currently years ahead of Cocoa in terms of API completeness. Of course, it has tons of obsolete garbage which is still there thanks to backward compatibility required by many popular 'pro' apps. But Cocoa looked like it's been only ported to PowerPC and debugged, rather than developed, for a couple of years, until key-value coding/observing. Cocoa, at least its public part, is sort of kept minimalistic. It's certainly good enough to write great apps with, probably doesn't need that many details as Carbon does, but if you compare the two, you see a great difference.

    Quote:

    Seriously, Carbon needed a heck of a lot of work to get the same functionality that Cocoa takes for granted in some areas, and in others, Cocoa apps have to defer to Carbon calls. Like, say, QuickTime.



    That's why I'm calling Cocoa a poor cousin. I don't mean that Cocoa sucks (God forbid). In fact, such things as FSRef, QuickTime API and some other bloody guts of Mac OS must die, the sooner the better. Until then wrapping this crap in Cocoa objects won't do you any good, and some seasoned procedural programming veterans will claim that Cocoa is not ready for prime time.
  • Reply 17 of 21
    zozo Posts: 3,117member
    as Stevie boy said when they announced OSX waaaay back when...



    "we're keeping the crown jewels and getting rid of the rest and combining it with a new architecture" (I'm paraphrasing, but he did say the "crown jewels" bit)



    The crown jewels is what we know as Carbon.



    Also, as the name implies, carbon is foundation of life, of everything.



    I dont think they'll be killing off their foundations anytime soon
  • Reply 18 of 21
    kickahakickaha Posts: 8,760member
    Quote:

    Originally posted by costique

    Hmm, really? Not to delve into political reasons, I'll just note that Apple is paying close attention to the needs of big 3rd party developers. Who are they? Mainly audio/video production, graphics/prepress and the like. Most of them don't work with ObjC for reasons of their own, mainly because they use PowerPlant or have their own frameworks in C/C++, obsessed with performance or simply not willing to invest in learning ObjC - it doesn't matter. They seem to constitute a majority of ADC Select and Premier members. And they are pushing Carbon just because they depend on it. And Apple cannot ignore them and tries to perfect Carbon as much as possible.



    Absolutely true - Apple is over a barrel, and they are indeed refining Carbon... but you'll notice they're not refining the API all that much, they are instead working on the inner pieces, moving Carbon (the API) over the top of the Core* libraries. Why? Because Cocoa can also benefit from Core*.



    Apple's stance has always been, and *continues* to be: "Use Carbon for legacy products, but any *new* applications should be written in Cocoa - that's the future."



    Carbon is legacy.



    Quote:

    What we have right now is that if you want to do something advanced (receive more event notifications in your run loop, convert text to an uncommon encoding, compose non-trivial AppleEvents, utilize CoreAudio, modify resource forks, access HFS features, and so on, and so forth) you have to use Carbon.



    Um, not really. Events: nope. Convert text: ATSUI is C, not Carbon. AppleEvents: yes. CoreAudio: Not Carbon. Resource forks: deprecated! Access HFS: Not Carbon... but of course you can tap into the IOKit.



    I think you're under a misassumption that anything Cocoa is automatically Carbon... not so. Carbon is a suite of legacy APIs, that's all. As soon as you start calling a Core* library, or anything in the new driver architecture, you've moved outside of Carbon.



    You do indeed need to drop into *C* on a regular basis in Cocoa, but guess what... Obj-C *IS* C. It's not exactly a big deal, y'know?



    Quote:

    Carbon is currently years ahead of Cocoa in terms of API completeness.



    I guess that depends on what you consider the criteria for complete. Cocoa is years ahead of Carbon for little things like ease of use for complex behaviour, and such.



    Quote:

    Of course, it has tons of obsolete garbage which is still there thanks to backward compatibility required by many popular 'pro' apps. But Cocoa looked like it's been only ported to PowerPC and debugged, rather than developed, for a couple of years, until key-value coding/observing.



    Probably because it didn't *NEED* the major overhaul that Carbon did? Seriously. Cocoa was, from Day 1, a highly robust and battle-tested API. Carbon was new, and still in a lot of flux. Of course Carbon is going to get the lion's share of the work, given finite resources... it *needed* it.



    As someone who specializes in software maintenance, this was telling to me - the system that *requires* more work to get it up to snuff, add new features, and keep it going, is simply not well designed. In this case, the Carbon group has done a great job of making an old crufty insanely convoluted API (Toolbox) look almost modern, and they've continued to refine it and improve it. My hat is off to them. But they are limited by the legacy uses of the API, and the limitations of procedural languages and the mindset of hardcore procedural programmers.



    Quote:

    Cocoa, at least its public part, is sort of kept minimalistic. It's certainly good enough to write great apps with, probably doesn't need that many details as Carbon does, but if you compare the two, you see a great difference.



    Yes, you do. I'm sorry, but I think this is simply a difference in programming methodologies here. *I* see an API with a bazillion functions exposed at the top layer, and my first thought is "Holy crap, that's a badly designed system." Ie, Carbon. Cocoa *looks* minimalist at first, but the depth is astounding.



    This is the difference between procedural and object-oriented systems - the former expose everything at once (because it is forced to by the language), while the latter exposes only what it needs to, when it needs to. It's an approach based on intelligent abstractions and encapsulation... and Cocoa *excels* at this. It's really quite astounding.



    Quote:

    That's why I'm calling Cocoa a poor cousin. I don't mean that Cocoa sucks (God forbid). In fact, such things as FSRef, QuickTime API and some other bloody guts of Mac OS must die, the sooner the better. Until then wrapping this crap in Cocoa objects won't do you any good, and some seasoned procedural programming veterans will claim that Cocoa is not ready for prime time.



    Well duh, they're *procedural* programmers... Cocoa/Obj-C/OO unnerves them. Frankly, there are some folks who never understand it, or for some reason, refuse to. These folks, *particularly* if they are 'seasoned' veterans with a large investment in the procedural world, are never going to accept a new methodology as anything but a threat to their bread and butter. I see it all the time in industry and academia. New doesn't always mean better, but to try and evaluate an OO system from *procedural* guidelines is just plain wrong, and is never going to result in a good evaluation. It's the wrong approach, plain and simple.



    I'm not saying Carbon sucks either - I think it's a solid procedural API that has overcome a multitude of large limitations rather well. But compared to Cocoa? No contest in my mind.
  • Reply 19 of 21
    costiquecostique Posts: 1,084member
    Quote:

    Originally posted by Kickaha

    Carbon is legacy.



    Sure.

    Quote:

    Events: nope. Convert text: ATSUI is C, not Carbon. AppleEvents: yes. CoreAudio: Not Carbon. Resource forks: deprecated! Access HFS: Not Carbon... but of course you can tap into the IOKit.



    We can argue about it a lot, I see your point and it's my fault I wasn't precise enough.

    Events. I'm not sure whether you can receive NSNotifications about all launched/terminated processes, and, probably, this is a design decision since it has to do with CFM/Mach0 differences, if I'm not mistaken - it's very straightforward in Carbon. However, in the world of Mach0 apps, which is the future of OS X, it won't matter or be of any use.

    Text convertion, as I checked, can be done in CoreFoundation - you're right.

    CoreAudio. I was surprised to see that the damn thing uses FSRef, especially in audio files calls. If you only knew how I hate it... Yet you're right - CoreAudio is not Carbon and, in fact, it's one of the most brilliant things from Apple.

    Resource forks. I too was under the impression they are deprecated, and Apple told everybody so, but now I'm not quite sure. I haven't looked at it myself, though, but I heard that the recent HFS+ development takes a number of forks for granted. If they were really deprecated, why even bother to talk about it? Probably, Apple will use them for some good private purposes, and they will indeed be deprecated in terms of applications' and files' resource forks. I just don't know. Meanwhile, there are tons of legacy font suitcases, apps with resource forks (iTunes, for example), etc. We still have to live with it. Personally, I have mixed feelings about them.

    Quote:

    I think you're under a misassumption that anything Cocoa is automatically Carbon... not so.



    No.

    Quote:

    Carbon is a suite of legacy APIs, that's all. As soon as you start calling a Core* library, or anything in the new driver architecture, you've moved outside of Carbon.



    Exactly. Carbon is sort of compatibility bridge between old system calls and new system architecture. I admit that I have to deal with Classic and legacy stuff too much - that's where Cocoa is not self-sufficient. One day, I hope, we'll leave it all behind.

    Quote:

    Cocoa is years ahead of Carbon for little things like ease of use for complex behaviour, and such.



    I agree.

    Quote:

    As someone who specializes in software maintenance, this was telling to me - the system that *requires* more work to get it up to snuff, add new features, and keep it going, is simply not well designed. In this case, the Carbon group has done a great job of making an old crufty insanely convoluted API (Toolbox) look almost modern, and they've continued to refine it and improve it. My hat is off to them. But they are limited by the legacy uses of the API, and the limitations of procedural languages and the mindset of hardcore procedural programmers.



    Aah, the toolbox... It was really crazy, that cocktail of Pascal and C. It even did not look like API.

    Quote:

    This is the difference between procedural and object-oriented systems - the former expose everything at once (because it is forced to by the language), while the latter exposes only what it needs to, when it needs to.



    Interesting. I never looked at it this way. It's not so obvious, perhaps, because, there is very OO-like plain C code and there is very un-OO-like C++ code. And, yes, the choice of language does influence style and thought.

    Quote:

    I'm not saying Carbon sucks either - I think it's a solid procedural API that has overcome a multitude of large limitations rather well. But compared to Cocoa? No contest in my mind.



    Absolutely. Even more so if you factor in the extensibility, relative ease of maintenance and readability. Cocoa is great. And it will improve with time as more and more developers get the taste of it.



    Thank you, Kickaha.
  • Reply 20 of 21
    kickahakickaha Posts: 8,760member
    Just a quick note...



    Quote:

    Originally posted by costique

    Resource forks. I too was under the impression they are deprecated, and Apple told everybody so, but now I'm not quite sure. I haven't looked at it myself, though, but I heard that the recent HFS+ development takes a number of forks for granted. If they were really deprecated, why even bother to talk about it? Probably, Apple will use them for some good private purposes, and they will indeed be deprecated in terms of applications' and files' resource forks. I just don't know. Meanwhile, there are tons of legacy font suitcases, apps with resource forks (iTunes, for example), etc. We still have to live with it. Personally, I have mixed feelings about them.



    Indeed... but note that these forks are not resource forks. Multi-forked filesystems are quickly becoming the norm, but the old resource fork is indeed deprecated. The new forks are being used for system maintenance information, IIRC, keeping stats on each file with the file, for instance. As far as I know, all data that is considered in the file is still in the data fork, the 'normal' file fork. To Unix tools, etc, the file looks the same. You can blow away the extra forks and not lose your data. With the old resource forks, they were critical to your data and/or applications, and it was lost, you were easily hosed. Not so now. The extra forks are for added value under MacOS X, but the plain data file can still be passed around to other platforms safely.



    Quote:

    Aah, the toolbox... It was really crazy, that cocktail of Pascal and C. It even did not look like API.



    Yeah, it was... interesting. Pascal was a great choice back in '84, but as the industry moved to C, Apple tried to keep pace, and the result was messy.



    Quote:

    Interesting. I never looked at it this way. It's not so obvious, perhaps, because, there is very OO-like plain C code and there is very un-OO-like C++ code.



    Absolutely! You can write well abstracted procedural code just as you can write poor OO code. No language can fix a poor designer. It tends to cloud the issue when attempting to make black/white distinctions, to be sure (not that those distinctions are really all that valid to start with...), but in general, an API that exposes only the pieces it needs to for a particular task is more easily understandable than one that presents *all* possible interactions up front and requires a great deal of study to get it all down pat.



    Quote:

    And, yes, the choice of language does influence style and thought.

    Absolutely. Even more so if you factor in the extensibility, relative ease of maintenance and readability.



    You betcha. It's odd to consider, but Cocoa makes it easy to do highly complex things... but doing 'simple' (low-level) things takes quite a bit of digging to find the proper hook. Carbon makes the simple things easy, but requires you to build up your own solutions to the complex problems. Given the amount of testing and good design in Cocoa, I'm more inclined to trust them to get the simple stuff correct *for* me, and let me get to work on building the really cool stuff. Those few times I need to do low-level tasks, I can take the time to learn those specific things... the overall learning curve to get a highly complex app up and running will be less in most cases.



    Quote:

    Cocoa is great. And it will improve with time as more and more developers get the taste of it.



    Thank you, Kickaha.



    Wait, I'm confused... did I just win a debate?!?



    Thanks for the discussion.
Sign In or Register to comment.