macOS Carbon vs. Cocoa: A structured debate

[SC68Cal]

For many programmers, Carbon is a term that encompasses much of the C API set on OS X that Cocoa doesn't use, and isn't part of the BSD/POSIX API set. So part of the annoying debate misses out on C APIs that have been introduced that will likely be 64-bit (DiscBurning, CoreImage/CoreVideo/CoreAudio, etc).

This is exactly right. Carbon was written to make a fast transition and recompile for applications that were originally written for the MacOS.

 

[czeluff]

let me kill this thread

let me kill this thread, right here right now

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done!

cz

 

[iSee]

let me kill this thread, right here right now

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done!

cz

Yeah. Whether it's official or not, Apple's made its priorities clear. When something had to give, they cut Carbon features. They didn't cut Cocoa. They didn't push Leopard's ship date back farther. They made the choice to cut Carbon 64. It's going to be more of the same in the future.

Now, I don't think all of Carbon will really ever be deprecated. Apple will want to continue to support all the Carbon apps out there. But as Cocoa continues to grow, Carbon will remain static--shrinking even, as Apple finds more APIs it can get away with deprecating and even dropping.

This leaves cross-platform (Mac/Win or Mac/Win/*nix) development in an interesting spot. Typically, at some level, a cross-platform framework wraps native APIs in a platform neutral interface (or you implement a subset of one platform's APIs in terms of native APIs and call that your "neutral" interface). Cocoa hasn't usually been the API wrapped because using the pure-C APIs (inevitably including lots of Carbon APIs) is a more natural fit.

You could wrap Cocoa, but you've got a difficult choice because the Cocoa frameworks are only available on Mac OS. Either you've got to hide all the dynamic OO goodness of Cocoa from the generic API (in which case, what's the point), or you've got to implement equivalent functionality on the other platforms--a very difficult task. Even Java has not done this really well. MS is porting a subset of .NET to OS X for Silverlight, but it is really a very small subset that will only be appropriate for certain kinds of apps.

I guess Apple is going to have to finally release and support Cocoa on Windows and *nix and give cross-platform development a huge boost.

 

[MongoTheGeek]

let me kill this thread, right here right now

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done!

cz

So did I. Parts of carbon will be 64 bit. Namely all of the low level stuff. Parts of it won't be,n namely most of the GUI. How much is TBD.

That being said there is nothing that prevents C++ code from being 64 bit. There is nothing that prevents you from throwing a cocoa face on a carbon app. Done it myself.

I believe but I have no knowledge of how, that you can even mix 64 and 32 bit code together. 64 bit under the hood and 32 for the display. Honstly who really needs a an image with 32 quadrillion colors?

They have been getting people to mix and match these things for years. This is mnerly an attempt to drag people kicking and screaming into an easier to use pardigm. Don't worry. While Carbon will evnetually be going away, its not leaving anytime soon. Expect it to not be deprecated until at least 10.7

just my opinion.

 

[Fukui]

let me kill this thread, right here right now

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done!

cz

Yea, and judging from the clapping in the audience when it was announced, a supported decision.....

 

[garethlewis2]

Can we get one thing perfectly clear please.

Cocoa is not built on top of Carbon. Carbon appeared after Cocoa as a bridge for developers who coded on Mac OS 7,8,9. Cocoa is NextStep built from 1986 onwards.

It seems the instant someone sees CoreFoundation, they think incorrectly of Carbon. CoreFoundation is as its name implies the CoreFoundation of OS X on top of BSD. It is written in C as it doesn't represent a layer your application will need to use in everyday tasks. Nearly every single part of Cocoa is built on this. Carbon is buiilt on top of CoreFoundation, and Cocoa is built ontop of CoreFoundation.

What does Cocoa bring over Carbon? Nothing if you want to code primarily in C. If on the other hand you want to write a program with a dynamic OO language then you have to use Objective-C.

 

[Fukui]

++

 

[caveman_uk]

You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

The source for text edit is installed with the xcode tools. It's in

/Developer/Examples/AppKit/TextEdit

 

[gnasher729]

You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

Carbon will be available as 64 bit, once Apple evangelists get their ***es kicked by enough developers.

 

[gnasher729]

This is exactly right. Carbon was written to make a fast transition and recompile for applications that were originally written for the MacOS.

That was years ago. Since then all the transitional stuff has been deprecated in Carbon and has been thrown out by developers long ago. Carbon today is one of the finest APIs I have ever seen. And if you compare Carbon and Cocoa documentation - the question is: Which Cocoa documentation?

 

[whooleytoo]

Well, if you were correct about that, I would agree with you

Alright..alright.. I'm not a graphic designer so I've no idea what the cool kids are drawing with these days. But the point remains - it's the 'must have' application developers who'll determine when Carbon dies, Apple can only nudge them in the "right" direction by slowly strangling Carbon.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

As pointed out below, you can - in Cocoa at least. Just create an NSAction for the radio buttons and connect it in Interface Builder.

Just because the framework classes do a lot for you, doesn't mean you can't then customise it to suit your needs.

You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

TextEdit is one app mentioned, I think Sketch is another.

 

[garethlewis2]

Carbon may be very well written. Cocoa is also very well written. Apple, specifically Jobs wants applications written in Objective-C and now Objective-C 2.0. That rules out Carbon. Objective-C isn't difficult to program in. If you can code in C and have the smallest smidgen of access to SmallTalk or Java you could switch over coding styles in a week.

 

[mags631]

Regardless whether Apple deprecates all of Carbon or not, it is clear where the emphasis is being placed. This seems to be analogous to the debate: code in .NET or Win32 API directly? Maybe the API's are there (and maybe forever), but I'm guessing new capabilities and general support will be for Cocoa (akin to .NET).

 

[GothicChess.Com]

Carbon will be available as 64 bit, once Apple evangelists get their ***es kicked by enough developers.

Needless to say, this is about 100% opinion.

I am looking for facts.

 

[elppa]

Well pardon me for becoming the Chief Executive Officer of a company and graduating from being a daily coder!

I have been developing on the PC for the past 7 years, co-authoring the 2004 World Computer Chess Champion (see http://www.chessville.com/GothicChess/ComputerWorldChampionships.htm for example).

I program on the Mac as a hobby, and I am "diving back in" again.

By the way, I also wrote Blackjack Deluxe, a program that was voted one of Mac User's "50 All-Time Best Shareware Programs" in 1996.

So there!

I didn't know this, I wrongly assumed you were a pro programmer. So sorry.

That said, my advice still stands, Apple has made it clear that if you want to develop new apps for Mac OS X, then you should be looking to use the Cocoa frameworks.

 

[SC68Cal]

Needless to say, this is about 100% opinion.

I am looking for facts.

Something the greybeards haven't been in touch with since System 8

 

[gnasher729]

Carbon may be very well written. Cocoa is also very well written. Apple, specifically Jobs wants applications written in Objective-C and now Objective-C 2.0. That rules out Carbon. Objective-C isn't difficult to program in. If you can code in C and have the smallest smidgen of access to SmallTalk or Java you could switch over coding styles in a week.

That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

 

[gnasher729]

Needless to say, this is about 100% opinion.

I am looking for facts.

The arse kicking is fact.
Message to Steve Jobs: Sorry, mate, no 64 bit version.

 

[MacRohde]

That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

Right on!

It's easy enough to say "just rewrite in Cocoa 'cause it's even better" but if you've got a codebase and manpower invested in Carbon it might just not make any economical sense whatsoever.

 

[GeeYouEye]

Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

If you don't actually need a 64-bit UI (and really, how many people do?), then just write your computation code in a CLI app and just call it from your Carbon app.

Incidentally, I wonder if you can fork()/exec() from a 32-bit executable to a 64-bit executable...

 

[cblackburn]

That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

That is just completely untrue in every way. Attached is a sample I threw together in 10 mins showing the functionality you suggested.

I'm not saying carbon is useless or anything but 99% of what you can do in carbon you can do in Cocoa and, in my opinion, much better.

Chris

 

[SC68Cal]

That is just completely untrue in every way. Attached is a sample I threw together in 10 mins showing the functionality you suggested.

I'm not saying carbon is useless or anything but 99% of what you can do in carbon you can do in Cocoa and, in my opinion, much better.

Chris

I think I saw a sample of this, where they did the same thing in Carbon. I might be wrong here in my recollection, but it wasn't very pretty.

EDIT: Found it
Here

 

[jeremy.king]

That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

I guess that depends on what you sell. If its a shrink wrap kind of product, then a rewrite could add new features or UI fluff which would allow you to market it as a new version. New customers pay full price and existing customers have the option to upgrade at a discounted rate. This revenue will help offset your investment in development with the added benefit of future proofing yourself from the eventual deprecation of Carbon. You will most likely make gains in productivity as well as Cocoa development is often faster than Carbon. I consider that a benefit. Also, as you grow you will find a bigger pool of talented Cocoa developers to choose from. Another benefit.

Its a cost of doing business as a software development company, eventually you will rewrite/refactor/reversion/repackage. The longer you wait, the greater the risk.

You are right though, your customers only care about one thing - Does it work? They don't care if its Carbon, Cocoa, Java, or GTK...You as a business owner, need to consider both the long term strategy and technical direction of your company while pleasing customers at the same time. It's a difficult balance but claiming no benefit from a newer technology seems a little pessimistic.

 

[gnasher729]

Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

Oh come on. If you have code that runs on bigendian and littleendian machines, and that isn't written by complete morons, then switching from 32 to 64 bit is no problem at all. There are some people whose code runs on anything from ARM to Alpha and Itanium.

The difference is: The changes that might have been necessary to move from 32 bit Carbon to 64 bit Carbon, that was something that I could sell to management. There would have been _real_ speed differences, plus 64 bit is good for marketing. The changes to move from Carbon to Cocoa, that is nothing I would even try to sell, because it would just make me look like an idiot.

 

[GothicChess.Com]

Something the greybeards haven't been in touch with since System 8

Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>