[Spiffster]

I finished reading Learning Cocoa with Objective C, and am a decent C programmer. Now I'm not really fond of the OOP in Cocoa. Maybe because I haven't used it too much (can't think of any ideas for apps- suggestions welcome ). But now how does carbon go about programming. Is it all procedural, or OOP? Are there any drawbacks to programming in Carbon? Is it easier to use than Cocoa? I'm not opposed to learning C++. Any suggestions, explainations, etc welcome.

[tikki]

Carbon is procedural.

I come from a C background as well, and do Cocoa, but I agree on not being fond of the Object Oriented thing. Maybe its just because I can't fully understand it. I dunno.

Stick with Cocoa if you already pushed through the book. Even though I am not OO god, I am getting decent at Cocoa (well, for me at least).

[smeger]

As with all things, it essentially comes down to a matter of preference. Here's mine: Cocoa rules, Carbon sucks.

Carbon is procedural, except for when the procedures are wrappers for stuff that's object-oriented "behind the scenes", like Quicktime and AppleEvents. Carbon began life as Pascal code, so some of it still reflects that heritage. Later stuff is straight C, and things that came still later are the nasty procedural wrappers for object-oriented stuff I mentioned a moment ago.

Different areas of Carbon use different design methodologies. For example, in older areas, "getter" functions return the value you're trying to get. In newer functions, almost everything returns an error code and you pass a pointer to the value you want to retrieve.

Most of the areas of Carbon (Carbon is huge by the way) contain old, crufty APIs that creak when you call them. For example, whenever you specify a callback function (for example, a function that gets called when a timer fires), you have to wrap it using a mechanism that was originally intended to bridge the gap between 68k and PPC code and then later became a shim for a change in the way executables were packaged. Yick.

To get anything done in Carbon, you need to call 38 functions, check 43 error codes, dispose of 14 chunks of memory that were allocated, look up the docs for 49 calls to make sure you don't need to dispose of memory for them too, and finally, uhhh, do something witty that I can't think of to end this sentence.

Contrast this with Cocoa - it's clean, rational, follows a (mostly) uniform design, and most importantly, gives you lots of functionality without you having to work for it.

There are reasons to use Carbon - good ones. But for new development that's not solely using Carbon-specific technologies, I don't recommend using it.

[Angus_D]

Carbon is getting more OO with things like HIView and stuff (it's getting all C++ internally), but Cocoa is widely regarded as being easier and faster to develop with.

[Gametes]

And take it from me, as weird as it seems at first, it's actually very logical. I moved from programming my TI calculator to Cocoa and after doing the first 3 tutorials on O'Reilly I dove into my own first app. After some rough spots (most of which you can find on this forum), I feel things are moving along smoothly. Cocoa does so much for you, I only last week had to learn what pointers did. The hardest part is learning all the APIs.

Now if only my iBook would get back from the shop, I could finish my app by April...

PS - to all the cocoa fans: is getThingy(x,v,q,y,t) - > [myThingy thingy:x forOtherThing:v withNumber:q ...] the most awesome thing or what? Keeps everything so... [/i]visible[/i].

[joshjacob]

I just don't consider Carbon and Cocoa the same. Cocoa is an object oriented application framework and Carbon is a set system APIs.

Would you consider stdio on the same level as Cocoa or Carbon?

I think Cocoa should be compared to frameworks like PowerPlant. PowerPlant is an object oriented application framework.

Carbon sits behind things like REALBasic, FutureBasic, PowerPlant and dozens of other frameworks. If you like the procedural style of C you can program Mac OS X using the Carbon APIs. But if you want to build an application then you should compare Cocoa against these other frameworks.

Some of the frameworks that Carbon powers have as many advantags as Cocoa. Other have the added benefit of being cross platform.

Those are just my head cold medicine induced comments. No one need reply or agree




- josh jacob


PS --

Notice how Cocoa gives you access to non-frameworked (is that a word) system APIs delivered via Carbon. The various C++ frameworks allow the same thing -- don't see something implemented or implemented how you like it, then you can roll your own.

[phidauex]

I've got both the Learning Carbon and the Learning Cocoa books from O'Reilly, and while I came into it from a knowledge of C, Cocoa is actually proving easier to learn.

Carbon isn't as yucky as many people make it out to be however, and to be frank, you can't really escape it. You have to call the Carbon API in many Cocoa programs if you want to do anything on a lower level, and sometimes to optimize things to speed them up. For instance, my app that connects to the keychain does it through Carbon calls to get in on a lower level. If you want to connect directly to hardware, like the CDrom drive, usually the best way is through carbon.

Frankly, its not a big deal either way. With cocoa, its easier to add the little touches that make OS X applications sweet, like services, spellchecking, etc. Its all set up and ready to go, you just need to activate the functionality.

I prefer Cocoa, but I think its silly that many people are very anti-Carbon. There are very legit reasons for using it, and in many cases, a Carbon application will be faster than the Cocoa counterpart. They are just different tools.. If you are really good at C, you might find Carbon easier to jump into, but if you want to learn some OOP, then Cocoa can make life very easy for you.

Maybe just do what I did and get both books, then you can learn a bit about both, and see which one works better for your needs.

Peace,
sam

[gralem]

definitive answer: cocoa

[Angus_D]

Originally posted by phidauex:
Carbon isn't as yucky as many people make it out to be however, and to be frank, you can't really escape it. You have to call the Carbon API in many Cocoa programs if you want to do anything on a lower level, and sometimes to optimize things to speed them up. For instance, my app that connects to the keychain does it through Carbon calls to get in on a lower level. If you want to connect directly to hardware, like the CDrom drive, usually the best way is through carbon.

Actually, for low-level Keychain access you'll probably want to use the Security framework and for low-level device access you'll probably want IOKit, neither of which are actually Carbon.

[phidauex]

You are right, Angus, I was going about it in a dumb way. I'm going in through the Security framework now, and its all coming together much better.

But that doesn't mean carbon is useless

peace,
phidauex

[GRAHAMUK]

Neither Carbon nor Cocoa sucks.

Cocoa is best if you ONLY want to develop for Mac with OS X, and have no cross-platform issues. In itself, it is a fabulous way to program. If you have no legacy of Mac programming, Cocoa is the best way to start.

Carbon is best if you need to develop for both OS X and the classic OS, or have cross-platform issues, which are usually easier to solve with a lower-level approach such as Carbon. Carbon is also easier for Mac developers who have been working with the Mac in the past, as most of it will seem familiar.

Carbon is only a set of APIs, Cocoa is a much more complete framework. However, there are frameworks for Carbon, such as PowerPlant and my own more lightweight MacZoop, so going the Carbon route does NOT mean you can't use OOP.



MacZoop is here

[Chuckit]

Originally posted by GRAHAMUK:
Cocoa is best if you ONLY want to develop for Mac with OS X, and have no cross-platform issues. In itself, it is a fabulous way to program. If you have no legacy of Mac programming, Cocoa is the best way to start.

Carbon is best if you need to develop for both OS X and the classic OS, or have cross-platform issues, which are usually easier to solve with a lower-level approach such as Carbon.

Correct my if I'm wrong, but isn't Cocoa actually more cross-platform? I mean, it's based on the Yellow Box API, which has been brought (via GNUStep) to basically every major platform out there, whereas Carbon is only implemented on Mac OS 9 and Mac OS X.

[clarkgoble]

Dumb question, but one that may soon be relevant for me. How hard is it to mix Cocoa and Carbon?

[GRAHAMUK]

Chuck, you are quite correct about Cocoa in that it's basically a new version of OpenStep and hence historically available on many more platforms than Carbon.

However, in real world cross-platform coding terms, Carbon can be the better bet, because most code will split into a core platform independent part (probably already written in C or C++) and a GUI platform dependent part, and in Carbon that division is more obvious and easier to deal with, though I believe Cocoa is a lot better than it was in this respect. I come from the Carbon angle though, havingbeen programming the Mac now for 16 years, so my perception of Cocoa may be a little off - I intend to learn Cocoa properly instead of just dabble, first impressions are very favourable, but I just don't know what it can do in the limit.

[Rickster]

Dumb question, but one that may soon be relevant for me. How hard is it to mix Cocoa and Carbon?

In general, it's much easier than people tend to think. Cocoa already links and imports Carbon, so you can call most any Carbon API from within your Objective-C code. If you take a look at Omni's open-source frameworks, you'll see we've been doing it quite a bit for such things as AppleScript, the Resource Manager, icons, and more. And Apple has new API and documentation for using Cocoa from Carbon, too.

(There are a few specific problem areas that are pretty nasty, though. Putting Carbon controls in a Cocoa window remains a pretty thorny issue, for example.)