PDA

View Full Version : Carbon and Cocoa. Your opinions.




Soulstorm
Aug 15, 2006, 03:28 PM
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
Aug 15, 2006, 03:46 PM
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
Aug 15, 2006, 03:59 PM
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
Aug 15, 2006, 04:14 PM
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
Aug 15, 2006, 05:03 PM
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 :D 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
Aug 15, 2006, 05:48 PM
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
Aug 16, 2006, 01:46 AM
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
Aug 16, 2006, 01:57 AM
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
Aug 16, 2006, 01:59 AM
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
Aug 16, 2006, 02:41 AM
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
Aug 16, 2006, 06:08 AM
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
Aug 16, 2006, 06:36 AM
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 wordYou'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
Aug 16, 2006, 08:18 AM
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
Aug 16, 2006, 08:28 AM
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: spell checking
find and replace
font/text controls including kern, ligatures, underline, multiple underline, strike through, multiple strike through, drop shadows, smart quotes
word/line/character count
support for imagesIn 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.

http://www.shawcomputing.net/racerx/cocoa-carbon.gif
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
Aug 16, 2006, 10:12 AM
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 :rolleyes: Now, spotlight....that is carbon only....isn't it?

slooksterPSV
Aug 16, 2006, 11:42 AM
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
Aug 16, 2006, 11:53 AM
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
Aug 16, 2006, 12:55 PM
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: spell checking
find and replace
font/text controls including kern, ligatures, underline, multiple underline, strike through, multiple strike through, drop shadows, smart quotes
word/line/character count
support for imagesIn 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.

http://www.shawcomputing.net/racerx/cocoa-carbon.gif
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
Aug 16, 2006, 01:25 PM
...
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. :eek: 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
Aug 16, 2006, 03:21 PM
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
Aug 16, 2006, 03:40 PM
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
Aug 17, 2006, 07:26 AM
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
Aug 17, 2006, 08:40 AM
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
Aug 18, 2006, 03:16 PM
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
Aug 18, 2006, 04:30 PM
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.

bousozoku
Aug 18, 2006, 04:49 PM
I don't think this is true at all.

Quite the opposite in fact.

It's not always true but it is often true.

Cocoa itself is slow because of Objective-C. Objective-C is a superior programming language but just like its mentor Smalltalk, it spends more time thinking than C and since C++ exception handling has been improved over the years, you can add that C++ is faster than Objective-C, as well.

Object-oriented languages take more time to do their job. C++ is generally fast because more than half the time, people aren't using any object-oriented features. Hybrid languages are like that. Of course, if they kept track of their memory usage, it might slow down quite a bit but there would be fewer memory leaks.

RacerX
Aug 18, 2006, 04:50 PM
<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>Well, would you care to add a none flawed example. I just put the same text into Photoshop on my system and got the same results. Outside of AppleWorks and Photoshop/ImageReady, I don't have any other Carbon apps the work with fonts. The rest of my apps are Cocoa based.

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.Quite aware of it actually, as in earlier versions of Mac OS X it caused many problems with apps that should have been problem free. I know developers who had to tell people that there wasn't any thing they could do about a certain function crashing their app because it had to do with Carbon and they were waiting on Apple to fix the issue.

In fact part of the reason that I didn't use Mac OS X as much as Rhapsody before 10.2 (even though I was using the same application titles on both systems) was because 10.0/10.1 made apps that had been rock solid in Rhapsody (under Yellow Box) flakey in Mac OS X.

slooksterPSV
Aug 18, 2006, 05:03 PM
I don't think this is true at all.

Quite the opposite in fact.
You are absolutely right, Objective-C handles memory better because of how you allocate objects and the pool, the pool gives you a big advantage over basic memory operations.

slb
Aug 20, 2006, 03:34 AM
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?).

That has more to do with the fact Adobe doesn't want to have to rewrite all of Photoshop in Objective-C and Cocoa just for the Mac market, forcing them to maintain two very different codebases. Carbon happens to map well to the Win32 API, which is why all the cross-platform applications from the Windows world are Carbon apps. The only exception I know of is Adobe Lightroom, which has a different codebase for the Windows version.

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.

To be truthful, Cocoa is a lot faster on the Intel Macs, and as I understand it from some Arstechnica discussions on the matter, the NeXTStep frameworks always fit better into the x86 mold than the PPC mold. But Cocoa will always take a little more memory because it's a big set of object-oriented frameworks and an Objective-C runtime. But my goodness, they're so fantastic on the development side that I can't imagine not writing apps in it. Apple talks up Cocoa so much because it's the easier and sexier technology to develop with and makes things much faster.

Just be glad it's not as slow as .NET. I think it's pretty cool that next year, we'll be getting the automatic garbage collection advantage that Java and C# have had, but with the speed of native code.

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

Final Cut and Logic are Carbon (their codebases date back to before OS X), as are all Mac games ported from Windows.

Soulstorm
Aug 20, 2006, 05:31 AM
Final Cut and Logic are Carbon (their codebases date back to before OS X), as are all Mac games ported from Windows.
Actually, I mean some games that are mac-only and developped in Cocoa. As for FCP and Logic, indeed, I broadened my search and saw that what you are saying is indeed that way.

RacerX
Aug 20, 2006, 08:14 AM
To be truthful, Cocoa is a lot faster on the Intel Macs, and as I understand it from some Arstechnica discussions on the matter, the NeXTStep frameworks always fit better into the x86 mold than the PPC mold.I think a lot of that is based on some false assumptions.

By that logic, NeXT's frameworks would work better on 68k processors than Intel processors, which wasn't the case.

What most people are seeing in comparing Carbon and Cocoa on PowerPC is not normal PowerPC aspects, but Altivec enhanced aspects. Carbon was introduced, developed and being adopted by developers at about the same time that Apple started it's move to the G4. Most of the foundational transition to PowerPC for the Cocoa code base was done with the PowerPC 604 and G3 processors. On pre-Altivec systems the Cocoa line had quite a few advantages over the original Mac OS, even in the area of games.

When looking at the same game on the same hardware, but with two different operating systems, the Yellow Box environment (which became Cocoa) beat Mac OS 8 (which would become the basis of Carbon). The game was Quake II, the system was a 300 MHz Beige G3, the results are here (http://www.everythingmac.com/articles/quake2/page1/).

Between the introduction of Carbon in the Spring of 1998 and the release of Mac OS X v10.2 in the Summer of 2002, Apple put a massive amount of development effort into Carbon while Cocoa was left pretty much alone over the same period. In fact when looking at Mac OS X Server 1.2 on both G3 and G4 based hardware, the only real advantage on the G4 systems was from the faster clock speeds. Making Mac OS X Server 1.2 (and 1.2v3) G4 compatible didn't mean that they took advantage of Altivec, or that Yellow Box apps would either.

It was only after Carbon had reached (in old Mac developer's eyes) an equal footing with Cocoa that Apple gave both environments equal attention (which brought back the view that Cocoa was given special attention).

The main thrust of Apple's recent efforts with Carbon has been to integrate Carbon development within Apple's development tools (which has been resisted by some developers like Adobe). I believe (from what I've seen and heard) is that Apple's long term goal is to not have Carbon and Cocoa applications, but just have Mac applications.

Bare Bones Software has shown that with a little bit of effort many of the things we now view as unique to Cocoa apps can be used within Carbon apps. Apple is working to make that little bit of effort no effort at all in the future.

As for the underlying code, some day using C++ or Objective C won't effect the user's experience as much as it does now.

Sadly Apple has dropped continuing Java enhancements from Cocoa, but I think that had more to do with developers lack of interest than anything. Apple had very high hopes for Java when it was integrated into Yellow Box in Rhapsody. But developers in neither Rhapsody or Mac OS X devoted much time to Java based apps. Given that, Apple made (arguably) the right choice in moving on with Cocoa development without it.

Fukui
Aug 20, 2006, 11:20 AM
It's not always true but it is often true.

Cocoa itself is slow because of Objective-C. Objective-C is a superior programming language but just like its mentor Smalltalk, it spends more time thinking than C and since C++ exception handling has been improved over the years, you can add that C++ is faster than Objective-C, as well.

Objective-C 2.0 addresses a lot of what your talking about.
I don't know how much is not covered by NDA, but looking at the GCC sources you can have a look at what they are addressing.
Hint: Have a look at the 64-bit implementation.

As for Cocoa vs Carbon. Look at it this way, why should apple develop two basically complementary APIs that are designed to do the same things? Why should they have to implement new features twice? Answer: they shouldn't and for the most part, they are not. Thats why a lot of the additional frameworks mentioned above, whether implemented in C or Object C can be added to carbon or cocoa apps with little trouble.

wmmk
Aug 20, 2006, 01:10 PM
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

I've never been to a WWDC, but what is the general consensus on Cocoa Java there?

Soulstorm
Aug 21, 2006, 06:24 AM
As for Cocoa vs Carbon. Look at it this way, why should apple develop two basically complementary APIs that are designed to do the same things? Why should they have to implement new features twice? Answer: they shouldn't and for the most part, they are not. Thats why a lot of the additional frameworks mentioned above, whether implemented in C or Object C can be added to carbon or cocoa apps with little trouble.
Using the same logic, there shouldn't be C, but only C++. There shouldn't be Java, only C++. Or better, let's all adopt Objective C, since all things tat can be done with C++ can also be done with Objective C (or ObjC++).

The target for a development enviromnent or an API should not be to push developers make programs a certain way. It should be to offer as much sophisticated tools as possible, to offer them options. Programming is 2% the language's vocabulary, and 98% finding a way to solve a problem through logic. Well, every programmer has a different way of solving problems. That's why different API's must exist for the Macintosh platform, that suit the needs of as many programmers as possible.

And let's not forget that there are people from the windows or Linux world who don't want to give up their entire codebase in order to port their program by learning an entire new development environment.

savar
Aug 21, 2006, 11:57 AM
Everything else in one's frameworks folder, including Core Services, is neither Carbon nor Cocoa, no matter what language the exposed API is in.

I don't understand what you're talking about. If an API is exposed in Objective-C using Cocoa for runtime support, then it is a Cocoa API. If it is exposed in C using Carbon types, then it is a Carbon API. If it uses Unix types then it is a BSD API.

If you include anything from Cocoa/Carbon/BSD/Other, then you become a Cocoa/Carbon/BSD/Other API (respectively).

The real point is that you can mix and match these different APIs pretty easily.

savar
Aug 21, 2006, 12:04 PM
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.

Ohhh. Well I haven't tried to buy any books on Carbon, and I could see how you might be frustrated that there isn't much out there. However, Carbon hasn't changed much in many years. You could pick up a MacOS programming book from 1999 and most of it would be relevant. You should be able to find source code on apple's developer site that shows how to begin a Carbon app, set up an event loop, respond to events, etc.

If you're interested in calling Carbon APIs, its as simple as calling a C function. The frustrating part in my eyes is that Carbon defines a lot of its own types and its not always obvious what they are used for, or what underlying type actually is. Learning these is simply a matter of skimming through files like Types.h.

I'd like to suggest there are a lot of APIs you can use in OS X. Cocoa and Carbon are both mainstream, but it is possible to write windowed applications using RealBasic, Python, Java, X11, AppleScript, etc. For an application which is mac-only and needs to perform fast, Cocoa is probably the best choice anyway: it is the quickest path to getting the most functionality.

Fukui
Aug 21, 2006, 06:22 PM
Using the same logic, there shouldn't be C, but only C++. There shouldn't be Java, only C++. Or better, let's all adopt Objective C, since all things tat can be done with C++ can also be done with Objective C (or ObjC++).

The target for a development enviromnent or an API should not be to push developers make programs a certain way. It should be to offer as much sophisticated tools as possible, to offer them options. Programming is 2% the language's vocabulary, and 98% finding a way to solve a problem through logic. Well, every programmer has a different way of solving problems. That's why different API's must exist for the Macintosh platform, that suit the needs of as many programmers as possible.

And let's not forget that there are people from the windows or Linux world who don't want to give up their entire codebase in order to port their program by learning an entire new development environment.
Thats not what I'm talking about at all.
I'm not talking about languages, I'm talking about re-implementing things twice, in two distinct apis. For example, carbon events and cocoa events etc....

What apple should be doing, and they are, believe me, is providing bindings to other languages. I can't reveal some of the new stuff, but look at quartz, you can program in either C or python. There's nothing wrong with having a C++ binding for cocoa, I think that would possibly take the complaints away that some developers have.

But its a waste of resources to do two distinct apis that do arguably the same thing but in different ways, think of the maintenance costs. Does MS still upgrade MFC to do the same things that .NET can do or do they provide language interops...

bousozoku
Aug 21, 2006, 08:10 PM
...
But its a waste of resources to do two distinct apis that do arguably the same thing but in different ways, think of the maintenance costs. Does MS still upgrade MFC to do the same things that .NET can do or do they provide language interops...

Considering how little MFC does, could it hurt?

Cocoa and Carbon do cover a lot of the same ground and, if you're not concerned with deploying your product on multiple platforms, you should go with Cocoa.

Binding Cocoa to C++ would seem particularly difficult because C++ is not much like Objective-C or Java. Considering that there are several applications frameworks (of varying quality) out there, Apple might consider aligning themselves with one like Qt that supports Windows reasonably well. If they would support such a framework along with Cocoa, they might have a lot more support from multiple platform developers.

gekko513
Aug 22, 2006, 06:12 AM
Binding Cocoa to C++ would seem particularly difficult because C++ is not much like Objective-C or Java. Considering that there are several applications frameworks (of varying quality) out there, Apple might consider aligning themselves with one like Qt that supports Windows reasonably well. If they would support such a framework along with Cocoa, they might have a lot more support from multiple platform developers.
That's an interesting idea. If Apple made Xcode and OS X the best platform to develop cross platform Qt apps on, they might lure many developers over on OS X, especially since the developers could test their apps on Windows and Linux also on the same computer.