macOS Carbon and Cocoa. Your opinions.

[Soulstorm]

No, it's not one of those "What to choose from the 2" threads. I just had something I want to make clear in my mind.

I see that in OS X the Cocoa framework is very supported, with many books having it as their main theme, and many new programmers begin to use it, day by day. I think it's safe to say that there are more Cocoa devs out there than Carbon.

But is Cocoa really better than Carbon? I mean... Many developpers still say that the flexibility that Carbon gives them is unique, and a good Carbon application is much more organised than the equivalent Cocoa application.

However, I still see Cocoa to be upgraded and supported more often than Carbon. In addition, the books that have been out for Carbon are limited. I had bough the Learning Carbon book by Dan Parks Sydow, and it was absolutetly horrible (and very old - it is dated in 2001). Not being able to find a good reference or documentation that ould teach me from scratch (I have a very good C++ background), I moved on to Objective - C and Cocoa. But I still have my doubts over the capabilities it offers to developers in general.

I would like to hear something on this from you, guys. I want people to answer who have been involved with at least 1 of these two frameworks, because I am curious as to what programmers think upon this matter. Tell me what you use and why you like it (or dislike it).

 

[Sayer]

Cocoa is an application framework. That is, it has pre-built functionality for a lot of the mundane stuff that you have to write to make a usable application.

Carbon is an API, that is you use the Carbon functions to build your own functionality to create a usable application.

Carbon today has evolved a lot from Mac OS X 10.0 and does a lot of stuff for you "for free" compared to earlier OS X releases or even Classic Mac OS.

In fact a lot of Mac OS X is created using the lower-level APIs such as Carbon and CoreFoundation, even underneath Cocoa.

The main difference is that "new" software can be created in Cocoa faster than using Carbon APIs and without an app framework. Existing apps or apps that have to be cross-platform can benefit from Carbon's lower level access on top of which can be built a custom app framework that is cross-platform (abstracted from the OS).

You can even mix Carbon in a Cocoa app without any real problems; there are a lot of conversion functions to go back and forth from one API to the other.

Is there any preference from Apple? Definitately towards Cocoa, as most of the middle and upper managmement people came directly from NeXT. This has (IMHO) pushed Carbon to second-class citizen status as new snazzy features were added to Cocoa first, with Carbon getting basically the same feature in the next major point release of OS X (Toolbars is a big one).

Also (IMHO) Apple engineers deliberately tagged Carbon apps that use the resize "grow box" by using an obvious white box graphic instead of the simple diagonal lines used for the "grow box" in Cocoa apps. Technically any Carbon app can use the Cocoa-style "grow box" going back to 10.2, it is simply not the default look for Carbon app's grow boxes, and it is never highlighted anywhere that you can change the appearance very easily. Conspiracy or "Compatibility"? *shrug*

 

[Soulstorm]

That preference towards Cocoa is the one that annoys me. Hell, have you ever seen a decent Carbon reference or a good tutorial? Or even a good book? Cocoa is a great API, but Carbon must have something, too, since many devs (Adobe, and even Apple) stick with it (Finder is Carbon, right?).

 

[link92]

Carbon is OS 8.6 - 9.2's API, and is in OS X for backwards compatibility, to make porting Classic apps easier. Cocoa is OS X's API.

 

[DaveGee]

That preference towards Cocoa is the one that annoys me. Hell, have you ever seen a decent Carbon reference or a good tutorial? Or even a good book? Cocoa is a great API, but Carbon must have something, too, since many devs (Adobe, and even Apple) stick with it (Finder is Carbon, right?).

I'm just wondering why would any of this 'annoy' you? But for the little that it's worth here's my take on all of this.

Carbon was introduced as a CRUTCH for OS 9 Apps... A way to let existing 'classic Mac OS' code compile and run in the 'new' OS X environment. Most everyone should agree that without Carbon *AND* Classic, OS X was DEAD ON ARRIVAL.

People can debate this all they want but the fact is Cocoa was and is the "Framework of Favor" in OS X and Carbon was/is the pacifier initially for all the developers and then (longer term) a MAJOR CRUTCH for those developers with big and apps that they simply couldn't (more to the point WOULDN'T) rewrite from the ground up in Cocoa.

Problem is once a baby gets a pacifier they don't EVER want to give it up and this leads us to the problem we have now... Mammoth apps that should have been received ground up rewritten (preferably in Cocoa) TWO or more years ago are still blubbering along in Carbon...

Oh, and it's not just that... They're still being developed in CodeWarrior an environment that's been considered a 'dead end' on the Mac for quite some time to all but the most stubborn die hard developers.

Pretty sad behavior for 'professional companies' (cough MS cough Adobe) continuing to blindly rely on a KNOWN DYING/DEAD development IDE without any substantial plan (that I could see) to migrate to something with a FUTURE. Then they had the nerve to acted SHOCKED when Apple announced their move to Intel. MS and Adobe new darn well that looking to CW wasn't going to be viable option and then proceeded to insinuate that their products not being available in UB was in some way Apples fault. Maybe not insinuate but come right out and say UB versions weren't going to be available for 'quite some time'.

Sorry but if you get SLAPPED in the face with advice from Apple and then choose to ignore the slap it's not Apple's fault.

Over the past few WWDC's that I've attended the following items were quite clear.

1 - Use Xcode, period end of sentence.
2 - New App? P-L-E-A-S-E consider Cocoa (tons of stuff 'for free')
3 - Carbon will continue to be .... uhhh ... supported ... yea thats it.
4a - Cocoa gets all the 'COOL NEW STUFF'
4b - Carbon sometimes get *some* of the 'COOL NEW STUFF' Cocoa got... sometimes...
5 - Java ... well uhhh it's good for 'server stuff'

Dave

 

[Super Macho Man]

Problem is once a baby gets a pacifier they don't EVER want to give it up and this leads us to the problem we have now... Mammoth apps that should have been received ground up rewritten (preferably in Cocoa) TWO or more years ago are still blubbering along in Carbon...

From the perspective of a user here who may or may not know what he is talking about, I think Carbon always gets an unnecessarily bad rap here and Cocoa always gets an unnecessarily good one. iPhoto (Cocoa) was the most bloated, inefficient, slow app in the history of computing until Aperture (Cocoa) stole that crown. If Adobe had rewritten Photoshop in Cocoa in 2001 I shudder to imagine how slow it would be and how many GBs of RAM it would need today. ALL Carbon apps I ever come in contact with are snappier and a lot more memory-efficient. I don't have any development experience but I suspect that any "blubbering" is happening only on the developer's side of things.

Photoshop and Office are continuing to evolve in their supposedly dinosaur-era development environments and Adobe and Microsoft can develop them in Pascal for all I care as long as they work for me (which they do) and perform well (also do). I'm sure Adobe has put some thought into the future of its flagship application on the star platform for that application.

Then they had the nerve to acted SHOCKED when Apple announced their move to Intel.

Everybody was shocked. It's not like Apple went psst to all the Mac developers 6 months beforehand. The Intel switch caught everyone by surprise and was totally unexpected.

 

[Soulstorm]

I'm just wondering why would any of this 'annoy' you? But for the little that it's worth here's my take on all of this.

I am annoyed because a C++ developer will have to choose an API that won't give him so many capabilities as he would expect. C++ is one of the most widely used languages out there. Objective C is easy to learn, you'll say, but you have to admit, that memory management is a pain in the *** !! Yes, XCode 3.0 will change all that, but still, people have the right to demand a high-performance API to program for the world's "most advanced OS".

From the perspective of a user here who may or may not know what he is talking about, I think Carbon always gets an unnecessarily bad rap here and Cocoa always gets an unnecessarily good one. iPhoto (Cocoa) was the most bloated, inefficient, slow app in the history of computing until Aperture (Cocoa) stole that crown. If Adobe had rewritten Photoshop in Cocoa in 2001 I shudder to imagine how slow it would be and how many GBs of RAM it would need today. ALL Carbon apps I ever come in contact with are snappier and a lot more memory-efficient. I don't have any development experience but I suspect that any "blubbering" is happening only on the developer's side of things.

A good-written application is snappier than a bad-written. That means that the fact that many cocoa programs are slow, is because of bad programming.

As for iPhoto, yup, it's slow. But only because it's making things on-the-fly. That's why Aperture is also slow.

But I know many cocoa applications that are fast and efficient, such as Final Cut Pro, Audio Hijack, and many games (and let's not forget Logic Pro. My father is a proffessionnal musician and Logic Pro-Cocoa is 3-4 times more efficient than the latest release of Cubase - Carbon).

And, gentelemen, I know many devs who say that there is more to Carbon than we think it is, it's just that Apple hasn't advertised these things, just to persuade people to move to Cocoa, since implementing a new feature for the Cocoa framework is easier than implementing it for Carbon.

And it's not just adobe that believes in Carbon. There are many programs that are carbon. Maya, Cinema 4D, Vue 5 Infinite, and all of these programs (except perhaps for Vue) have GREAT performance and stability... And if these people (and Adobe, which I believe are great fans of Apple) stick with Carbon, they must have done it for a reason, and I believe I know what it is.

They don't want to rewrite their applications using Objective C or Objective C++. And why would they have to? Apple should provide them with the best Carbon API they could make, so that they have an easy time moving their projects to OS X.

That's why I'm annoyed. Because OS X developers always say about microsoft "you can program for .NET with any language as long as this language is C#", and now, apple does the same thing with Carbon-Cocoa.

Don't get me wrong. I love Cocoa. But am really p***ed off that apple didn't give me any other option (Carbon books and references suck).

 

[bousozoku]

I prefer Carbon because I prefer cross-system compatibility of applications.

Cocoa is a nice application framework that works well enough. Being that it's Apple-only for new equipment limits it. Objective-C is an extremely useful language that suffers from some odd syntax, though it doesn't suffer from odd features as C++ does and some performance problems, due to late binding and automatic garbage collection on certain items.

Still, if I'm not using Java, I'd rather use a C++ application framework over Carbon.

 

[Soulstorm]

Still, if I'm not using Java, I'd rather use a C++ application framework over Carbon.

Perhaps you mean "over Cocoa"...?

Does anyobody know any good book about Carbon?

 

[bousozoku]

Perhaps you mean "over Cocoa"...?

Does anyobody know any good book about Carbon?

Why would anyone create another framework over Cocoa? That would be ridiculous.

Carbon could use a framework with inbuilt behaviours, though it's quite acceptable in its raw form in contrast to Windows.

 

[caveman_uk]

And it's not just adobe that believes in Carbon.

I don't think 'believes' is the right word. Lightroom on the Mac seems to be written in a bunch of stuff including Cocoa. It's just that in Photoshop, Adobe has a massive app where the cost of porting to Cocoa simply isn't worth the reward. To be honest I was surprised to see Cocoa used in Lightroom. Maybe the cross-platform requirement got nailed onto the project specs really late in the day...

It's not true that Cocoa gets all the new toys. There's plenty of stuff that's only available through a C interface - Core Image for one.

I have to admit to being a little perplexed that people find memory management hard in Objective-C/Cocoa. Seriously, It's easy. 'If you alloc or copy it it needs releasing.' That's it. That's the rule. How hard is that?

 

[Soulstorm]

Why would anyone create another framework over Cocoa? That would be ridiculous.

Carbon could use a framework with inbuilt behaviours, though it's quite acceptable in its raw form in contrast to Windows.

My brain stopped working there and I thought you meant something else, sorry.

I have to admit to being a little perplexed that people find memory management hard in Objective-C/Cocoa. Seriously, It's easy. 'If you alloc or copy it it needs releasing.' That's it. That's the rule. How hard is that?

Following the same logic, people shouldn't have trouble with dynamic memory allocation in C++, but they do, even proffessionals.

It's not that Cocoa's style of memory management is difficult... it's just unique (none of the most popular languages have the same style of memory management) and many people have trouble adopting 'unique' styles. At least, that style guarantees efficiency and speed. But it takes time to master.

In C or C++ you don't have to worry about such things. Objects are released at the end of the scope, but if they are created dynamically, then you must free them dynamically. One of the unique points of Objective C's objects is that the same object's data exist even when we are out of the scope, until the retain count reaches zero. So, passing the data of an object outside it's scope can be extremely fast (since all we are copying are pointers), unlike C++, where in order to do the same thing using pointers, you need extra work and care. But as I said, Objective C's memory management is unique, and while new programmers can easily get used to this style, programmers that have been involved with proffessional programming for many years will find it difficult to abandon their codebases and be introduced to something entirely different.

I don't think 'believes' is the right word

You're right. It isn't a religion. But, as I said, my brain stopped working there, and i made some logic errors in my post.

 

[grabberslasher]

It's not true that Cocoa gets all the new toys. There's plenty of stuff that's only available through a C interface - Core Image for one.

Huh? Core Image is completely Cocoa, aside from CIKernels which are written in a C language like shaders are.*

 

[RacerX]

For me the difference between Carbon and Cocoa is the difference between the original Mac OS and NEXTSTEP/OPENSTEP.

The thing that Cocoa does is that it lets applications share some major and minor functions. Further, many functions that are common between applications are supplied by the operating system itself. This structure is broadly known as Services.

For example, using Carbon how long would it take you to write a basic word processor that had the following:

1. spell checking
2. find and replace
3. font/text controls including kern, ligatures, underline, multiple underline, strike through, multiple strike through, drop shadows, smart quotes
4. word/line/character count
5. support for images

In Cocoa such an app takes less than a day. Why? Because all of what I just listed is shared by either the system or third party services.

The idea behind Services is that no app should stand alone. Developers should concentrate on the unique function of their app and not items that have to be create anew for each app in Carbon. Further, the user can pick and choose what functionality they may want by collecting together a combination of apps and services. Basically letting the user build the functionality they need rather than wading through the mass of features included in most bloatware these days

I have examples of this throughout my system... like I don't like writing HTML source code when I'm writing, so I can write in TextEdit using rich text and then Create (a Cocoa illustration, page layout and web design app) will convert the rich text to HTML via a service Create shares with all other Cocoa apps. This isn't an ability native to TextEdit, but it is a feature I use within TextEdit all the time.

By contrast, Carbon applications stand alone. They don't share features, and any features they have have to be built into the app. This wastes a ton of development time (implementing something as simple as spell checking means creating the ability to spell check and including a dictionary) and leaves the end user with multiple versions of something that should have only existed once (multiple spell checking dictionaries means that adding a word to one doesn't change the dictionaries of the other apps which have their own).

And there is a difference in quality too. Look at any font that uses ligatures in a Carbon app like MS Word or AppleWorks and then look at the same font in TextEdit or Nisus Writer Express or Create. What you see is that Carbon apps use the standard ligatures throughout the text while Cocoa apps use dynamic ligatures which change depending on the adjacent characters.

On the left is an example of ligatures in Create (a Cocoa app) and
on the right the same text and font in AppleWorks (a Carbon app)​

How long would it take anyone to add that functionality to a Carbon app they are developing? What would you need to learn to do anything like that? You get it for free when developing a Cocoa app.

The idea that Adobe and other developers would have problems converting their apps to Cocoa is misleading. For example, Adobe had a native version of Illustrator for NEXTSTEP... and there was never a Carbon equivalent in NEXTSTEP/OPENSTEP. Similarly FrameMaker had a native version for NEXTSTEP/OPENSTEP, as did WordPerfect. And NeXT never had anywhere near the market share that Macs have now.

So it makes you wonder why is Illustrator Carbon? And why isn't there a Mac OS X version of either FrameMaker or WordPerfect?


For me, Carbon apps isolate me from a ton of functionality that I know is on my system... provided by tons of services. In some cases I don't notice it as much (like in Photoshop) as I do in others (GoLive, AppleWorks, Firefox). But I could never use something like MS Word now because I would feel crippled by not having access to things I know are there on my system.



What it comes down to is do you want your application to be alone on a system or part of a community on a system. Cocoa apps and the system share tons of features with your Cocoa app that would otherwise need to be created from scratch in a Carbon app.

People starting with a new application in Mac OS X need to ask themselves... is your time really best spent reinventing the wheel for many features, or do you want to skip all that and move onto the heart of the application you wanted to make?

 

[caveman_uk]

Huh? Core Image is completely Cocoa, aside from CIKernels which are written in a C language like shaders are.*

Yep, completely correct. I'm talking out of my arse again Now, spotlight....that is carbon only....isn't it?

 

[slooksterPSV]

My personal opinion:
Memory Management is my biggest issue with programming. Cocoa allows me to allocate, release, store, etc. all these objects without basically any extra lines of code. Now with Carbon, since its C++, I think you still have to use malloc, alloc, calloc, realloc, etc. My biggest fiend is malloc, maybe I wasn't fully taught how to use it functionally.
Anyways in Cocoa you create an object:

NSObject *myObject = [[NSObject alloc] init];
...
[myObject release];

In objective-c wasn't there a free function for standard objective-c objects? I think so.. -- Anyways beyond the scope of this comment.
Now in C++ to allocate a class -I can do this, I understand it- you do this:

MyClass *class = new MyClass();
...
//delete[] class
//delete class
//class->~MyClass();

How do you deallocate a class in C++? Honestly, I don't know, does it free itself or... I think you use delete class or if you have an array of them delete[] class;

So yeah, you can see some of my memory management woes. In Objective-C I feel confident, I can run another program that shows me where my leaks are if I'm leaking memory. Plus, now get this one, Core Data is Objective-C *jumps up and down with delight* Core Data is awesome.

Beyond scope, off topic, anyways I choose objective-c for memory management of objects. Also, with Objective-C you can store objects in arrays which is awesome! I did that with one of my apps, stored an array to an array to objects. It's so cool. How do you do that in C++?

 

[GeeYouEye]

I think there's a bit of misleading information here about just what Cocoa and Carbon are. Cocoa is an umbrella framework solely comprising Foundation.framework (better than the STL by light-years), AppKit.framework, and CoreData.framework. Period. That's it*. QT Kit, PDF Kit, Web Kit, Core Animation, Address Book*, and Core Image, while providing an Objective-C interface, and heavily utilizing Cocoa, are themselves not Cocoa.

*Pro Kit may also be technically part of Cocoa, but as it's private, it doesn't count. Address Book is on the fence.

Carbon is also not as big as everyone seems to think it is. Carbon is also an umbrella, but for the following frameworks: Carbon Sound, Common Panels, Help, HI Toolbox, HTMLRendering (possibly obsoleted by WebCore, possibly using WebCore now), Image Capture, Ink, Navigation Services, Open Scripting, Print, Security HI, and Speech Recognition.

Everything else in one's frameworks folder, including Core Services, is neither Carbon nor Cocoa, no matter what language the exposed API is in.

 

[grabberslasher]

For me the difference between Carbon and Cocoa is the difference between the original Mac OS and NEXTSTEP/OPENSTEP.

The thing that Cocoa does is that it lets applications share some major and minor functions. Further, many functions that are common between applications are supplied by the operating system itself. This structure is broadly known as Services.

For example, using Carbon how long would it take you to write a basic word processor that had the following:

1. spell checking
2. find and replace
3. font/text controls including kern, ligatures, underline, multiple underline, strike through, multiple strike through, drop shadows, smart quotes
4. word/line/character count
5. support for images

In Cocoa such an app takes less than a day. Why? Because all of what I just listed is shared by either the system or third party services.

The idea behind Services is that no app should stand alone. Developers should concentrate on the unique function of their app and not items that have to be create anew for each app in Carbon. Further, the user can pick and choose what functionality they may want by collecting together a combination of apps and services. Basically letting the user build the functionality they need rather than wading through the mass of features included in most bloatware these days

I have examples of this throughout my system... like I don't like writing HTML source code when I'm writing, so I can write in TextEdit using rich text and then Create (a Cocoa illustration, page layout and web design app) will convert the rich text to HTML via a service Create shares with all other Cocoa apps. This isn't an ability native to TextEdit, but it is a feature I use within TextEdit all the time.

By contrast, Carbon applications stand alone. They don't share features, and any features they have have to be built into the app. This wastes a ton of development time (implementing something as simple as spell checking means creating the ability to spell check and including a dictionary) and leaves the end user with multiple versions of something that should have only existed once (multiple spell checking dictionaries means that adding a word to one doesn't change the dictionaries of the other apps which have their own).

And there is a difference in quality too. Look at any font that uses ligatures in a Carbon app like MS Word or AppleWorks and then look at the same font in TextEdit or Nisus Writer Express or Create. What you see is that Carbon apps use the standard ligatures throughout the text while Cocoa apps use dynamic ligatures which change depending on the adjacent characters.

On the left is an example of ligatures in Create (a Cocoa app) and
on the right the same text and font in AppleWorks (a Carbon app)​

How long would it take anyone to add that functionality to a Carbon app they are developing? What would you need to learn to do anything like that? You get it for free when developing a Cocoa app.

The idea that Adobe and other developers would have problems converting their apps to Cocoa is misleading. For example, Adobe had a native version of Illustrator for NEXTSTEP... and there was never a Carbon equivalent in NEXTSTEP/OPENSTEP. Similarly FrameMaker had a native version for NEXTSTEP/OPENSTEP, as did WordPerfect. And NeXT never had anywhere near the market share that Macs have now.

So it makes you wonder why is Illustrator Carbon? And why isn't there a Mac OS X version of either FrameMaker or WordPerfect?


For me, Carbon apps isolate me from a ton of functionality that I know is on my system... provided by tons of services. In some cases I don't notice it as much (like in Photoshop) as I do in others (GoLive, AppleWorks, Firefox). But I could never use something like MS Word now because I would feel crippled by not having access to things I know are there on my system.



What it comes down to is do you want your application to be alone on a system or part of a community on a system. Cocoa apps and the system share tons of features with your Cocoa app that would otherwise need to be created from scratch in a Carbon app.

People starting with a new application in Mac OS X need to ask themselves... is your time really best spent reinventing the wheel for many features, or do you want to skip all that and move onto the heart of the application you wanted to make?

Yeah I'm with you Dave, after being introduced to NEXTSTEP, Openstep and Rhapsody and then OS X I really can't stand Carbon apps anymore. They feel archaic, always behind with features and less "interesting". I mean, sure the big apps are the same as ever, but Cocoa allows "cool" apps to be written much more easily.

I personally can't program Carbon apps, although I can make great stuff with Cocoa. I suppose it's a style thing - some people prefer the direct access Carbon gives you, so you don't have to link to tons of frameworks to do stuff, others prefer to design their app to look and work beautifully in OS X. It's a generation thing too, with the Carbon people generally older developers.

 

[bousozoku]

...
Following the same logic, people shouldn't have trouble with dynamic memory allocation in C++, but they do, even proffessionals.
...

It's especially professionals, not even professionals, have trouble with dynamic memory allocation. Most professionals should be using Pascal so they don't get into trouble. Programming languages that trust the average programmer--shouldn't.

In the early 1990s, there was such a wave of memory diagnostic tools because universities were churning out coders without good habits. Of course, corporate culture and looming deadlines certainly affect the outcome. Working in a place where rubber band fights may break out at any moment certainly can disrupt your coding process.

Of course, a good development environment could keep track of your memory allocation and de-allocation, the way it keeps track of variables or braces or parentheses.

 

[szymczyk]

In addition, the books that have been out for Carbon are limited. I had bough the Learning Carbon book by Dan Parks Sydow, and it was absolutetly horrible (and very old - it is dated in 2001). Not being able to find a good reference or documentation that ould teach me from scratch (I have a very good C++ background), I moved on to Objective - C and Cocoa.

The reason there are no modern Carbon books is economics. There are not enough Carbon developers to make publishing a Carbon book worthwhile. How many people would buy a Carbon book? I think 1000 at the most, and I'm being optimistic.

Computer book publishers typically print 3000 copies of a book and ship them to book stores to sell. They will not publish a book unless they think it has a good chance to sell the 3000 copies they printed. Even if an author could convince a publisher to publish a Carbon book, why would he or she want to spend 9-12 months writing a book for only $10,000 (US), which is the typical advance a computer book author receives?

The only way I can see a Carbon book being published is if Apple were to subsidize the publication. But I doubt they would ever do that.

 

[savar]

But is Cocoa really better than Carbon? I mean... Many developpers still say that the flexibility that Carbon gives them is unique, and a good Carbon application is much more organised than the equivalent Cocoa application.

Wow, there are a lot of replies here that I can't read right now but will come back to later.

Cocoa is the API of choice for future development. The main reasons for still using Carbon are that you already had an existing Carbon code-base, or else you had so much intellectual capital invested in Carbon that it wasn't worth the time/money/effort to retrain for Cocoa.

Still, its very easy to call Carbon from Cocoa (they are just C functions after all) and quite necessary depending on what parts of the system you want to use. For example, the last time I checked (summer of 06 I think), the Process Manager was still a very Carbon-oriented framework. I was writing a Cocoa app at the time and it seemed much easier to call the Carbon APIs than find a work-around in Cocoa.

I don't know if Cocoa can be called from Carbon. My gut tells me that such an idea is nonsensical -- Cocoa is more than an API, it's also a runtime environment. So it seems like if you wanted to call a Cocoa function (aka send a message), you would have to startup the entire Cocoa runtime to support the code that you're calling.

What is your real objective in asking this question? Mere curiosity or are you trying to decide which to learn or use for a new project?

 

[Soulstorm]

What is your real objective in asking this question? Mere curiosity or are you trying to decide which to learn or use for a new project?

I already said that I have already chosen what API I will use, and that is Cocoa. I'm just curious how everyone else feels about this matter, since, when moving to OS X development, you don't have any real option on what API you will choose, since Carbon references suck.

 

[gnasher729]

The reason there are no modern Carbon books is economics. There are not enough Carbon developers to make publishing a Carbon book worthwhile. How many people would buy a Carbon book? I think 1000 at the most, and I'm being optimistic.

The reason is that there isn't much need for a Carbon book. Carbon is just an API; all you need to know is the interfaces. Apple's documentation plus the header files are plenty to understand everything you need to know about Carbon.

 

[Catfish_Man]

The reason is that there isn't much need for a Carbon book. Carbon is just an API; all you need to know is the interfaces. Apple's documentation plus the header files are plenty to understand everything you need to know about Carbon.

You're joking, right? Cocoa is just an API as well, and a much easier one than Carbon... and yet people feel the need to publish tons of books about it. Beginning programmers don't have the ability to learn an API from its headers, and advanced ones often don't have time (reading a book isn't always faster, but it definitely can be).

One thing I'm not sure a lot of people realize is that most/all major Cocoa apps also use Carbon, because Cocoa doesn't include all the necessary functionality. The more modern (HIToolkit-based) Carbon apps are starting to use Cocoa as well, which is a trend that will continue in 10.5 as Cocoa-Carbon bridging improves further.

<edit>
Also, the Appleworks screenshots above are a flawed comparison, because Appleworks doesn't use any of the more modern Carbon APIs (it hasn't been updated since before they existed).
</edit>

 

[elppa]

ALL Carbon apps I ever come in contact with are snappier and a lot more memory-efficient.

I don't think this is true at all.

Quite the opposite in fact.