I think a Cocoa program is better than a carbon program in one major way for me.

Is it not true that programs written cocoa can take advantage of services and programs written as carbon cannot?

There are a lot of small utility programs that are written as services so that all cocoa programs have access to them. I like that.

True; the thing is not that Services functionality is not available to Carbon developers - its that to provide Services in a Carbon app much more effort is needed.

While it is true that the Cocoa frameworks use the carbon frameworks for quite a few tasks, the benefits of Cocoa outweigh the overhead, IMHO. Services alone make the Cocoa environment *far* superior to that of Carbon.

Services are great due to the network effect. The more applications that have them, the more the service [note small "s"] becomes useful. Services exist on the single-machine level at this point. What happens in a year when Apple releases an enhancement that [coupled with Rendezvous] will allow services from one machine to pass messages to another machine. Think Clustering.

Also, as you point out, RAD is much more useful with Cocoa than through Carbon. With the push toward multi-threaded applications, both frameworks need to be updated to be fully re-entrant. I can see the Cocoa frameworks being non-trivial but easier than the Carbon frameworks.

Unity. If everyone [yes, I know, it's not going to happen] writes using Cocoa, we will no longer have the disparity between interface elements [both GUI and non-GUI]. Most casual users don't realise that the keyboard accelerators in Cocoa apps behave differently than those of Carbon apps [emacs key bindings for an example]. Consistency is key. If everyone were to follow the Cocoa frameworks, they would inherit all the "freebies" that you don't get in Carbon applications. That is why I consider the Carbon frameworks to be second-class citizens in the OS X world. They aren't "bad" but they are not as robust as the Cocoa frameworks.

Key difference between the two frameworks:

- Because Carbon is a low level API / framework, the developer has to work very hard to make an app look/feel 100% "correct". Relatively easy / often repeated tasks can often require a lot of repeated, but slightly different, code across applications or within an application. At the same time, the developer has a tremendous amount of flexibility available to them -- the APIs can be made to do just about anything, given enough effort.

- Cocoa is a very high level API. It provides an awesome amount of power and consistency for free. Cocoa is also designed to solve a relatively general purpose set of development problems. As such, it is not highly optimized to any one particular development problem. While it is often trivial to create a powerful application that exhibits most of the desired features in a relatively short amount of time, it can be require a lot of effort to make the program work extremely efficiently.

As he said -- Carbon and Cocoa are just different.

However, with all that said, my experience with OS X has very much been that Carbon apps are typically inconsistent in their UI, often more buggy / less stable, and generally much more annoying to use than the various Cocoa applications I have run into. I have also found that Carbon applications will often use significantly more system resources when "idle" -- likely because of the WaitNextEvent() / GetNextEvent() legacy from which Carbon came.

Don't forget that Cocoa developers have access to the Carbon toolbox if they want it, and that Carbon developers can use nib files for UIs.

I'm an amature programmer who has attempted Classic programming and actually used Cocoa to write an application :)

I would say that while Cocoa/Objective C is fine for small applications mostly focused on the UI, Carbon would be better when speed is required. I tend to err towards POSIX myself.

Carbon & Cocoa are different today, this is true, and will likely remain true for a bit longer. However, Apple's goal is to make them extremely easy to switch back and forth between.

In 10.0 getting Carbon & Cocoa to behave together (UI-wise) was next to impossible, with Carbon really being 2nd class in a lot of things (although it could still do things Cocoa could not at the time).

In 10.1 Carbon got Services. The only real problem with Services in Carbon is that there isn't anything that can automatically manage them like there is in Cocoa. In Cocoa if you make a selection of some text, then the framework notes that and tells Services what you did, but in Carbon the programmer has to do it themselves.

In 10.2 Carbon & Cocoa UIs can be mixed at the window level -- that means that a Carbon app can host a Cocoa window and vice versa. I haven't tried this myself, but it looks promising and is a peek at what future plans are.

Post 10.2 Apple will make it possible to mix and match Cocoa & Carbon at the widget level - Cocoa popup menu & Carbon checkbox in the same window. That's the marketing spin on it (After all, Apple has to market to devs =). My theory is that this means that Cocoa is going to move to complete sit on top of Carbon. Of course, for this to happen really means that everything that Cocoa does today will arrive in Carbon, and must.

So if you really want to make a comparison, Carbon is like the little kid in those old Milk commercials. He may be a tiny little punk today, but someday that Super Model standing next to him will want a date!

I wouldn't say that "Cocoa/Objective C is fine for small applications focused on the UI". NeXTStep ran plenty fast on its second generation hardware (the original cube was slowed down by the slow optical drive) - a 68040 NeXT did many things as fast or faster than a comparable mac at the time. Granted, a lot of speed was gained from items like the DSP chip. But I remember seeing teachers let their Mac IIsi's leave a mandelbrot set running overnight, while a NeXTSTation Color could render the same set in a manner of seconds.

While it's generally a good idea to try to keep code optimized for speed, it's often a better idea to keep code maintainable and to present a rich user experience. NeXTStep and its descendants have always offered this by keeping AppKit fairly uniform, and flexible enough to move between platforms (it has run on Windows, Solaris, and the weird bastard child known as Mac OS X Server 1.x).

As for speed of PowerPlant vs Cocoa. An
application is not fast because of its API, Language, or Framework - it's fast because of design and implementation details. The Cocoa based Finder (known as WorkSpace Manager) on NeXTStep 2.0 on 68040 hardware was faster than the finder in Mac OS X 10.0 on a G4. It was comparable to the Finder in 10.1. NOW the Finder has finally gotten up to speed. And it finally has some of the cool inter-application communication and services that the original NeXTStep Workspace Manager. IE 5 had dismal performance as a Carbon app until recently. A lot of this has had to do with lack of use (or improper use) of Carbon Events. But for Apple's supposed flagship application, the Finder, to suffer speedwise like it did until Jaguar, is NOT a ringing endorsement for Carbon. While again - Workspace Manager ported fine to Mac OS X Server 1.x (which was essentially NeXTStep 5.x).

The point is - Cocoa can handle big jobs. It did fine in the past. Mathematica, Illustrator, and WordPerfect all ran on NeXTStep. The Mathematica and Illustrator versions we have today are Carbon apps, but I suspect this has more to do with the fact that NeXTStep was abandoned while those applications moved on. While it's not the fastest browser (due to design implementations), OmniWeb has moved more gracefully between versions of NeXTStep up to Mac OS X than IE 5 has done between Mac OS Classic and X.

I've always preferred dynamically (ie - at run time) patchable systems, even though they tend to be slower, than static systems that may run faster. As long as the speed difference isn't egregious, I think the dynamic systems ultimately offer better functionality and offer clean extension points. There was a small thing you could install into Mac OS X that patched any Cocoa textfield / textbox to allow auto-completed input. It did this through public API's and Services, similar to the automatic spell checking you get in all Cocoa apps. I just hope that Chimera starts using such text fields soon - a significant OmniWeb perk is the ability to use some EMacs key bindings and get spell checking in HTML TextAreas - all services offered by Cocoa.

Reasons I hate Cocoa apps:

NSLayoutManager behaves more like a Windows app than a Mac app. For example dragging DOWN on the right side will select the trailing linefeed of the last line selected. I hate this.

Cocoa apps tend to use POSIX file paths (in the form of NSStrings) as file pritives instead of FSRefs. This changes the behavior of commands like "Save". If you use NSDocuments for ALL file i/o you have the correct Mac behavior, but who the hell is going to do that for all file i/o?!

strobe, I see no difference "saving" files in my Cocoa app than in Carbon apps, except the fact that I can call one fuction and can write out my NSDictionary in XML. =) If you set the window's representedFilename to your file, you can move it, drag it via the proxy icon, etc and it will act like a FSRef (probably maps to an FSRef in fact).

Not to be an ass here, but it comes down to what runs faster on my powerbook - Cocoa apps run faster and are more stable than the Carbon ones. I am not sure what other analysis end-users are suppose to take from that simple fact.

shawn - to make any judgement/analysis, could you give us an example of cocoa applications that runs faster than carbon? =)

Any pointers on where to learn Cocoa/Objective-C?

Thank You
Recent Switcher

slava,

well there are hundreds of cocoa apps and carbon apps to compare... but let's take something like VNC - the cocoa versions of VNC are much faster than the carbon implementations I found. By faster I mean, the redraw the server screen faster and more readily accept mouse inputs.

dare I compare IE 5.2.1 to Chimera 0.5? probably not, but let's just say for a "beta" app, Chimera crashes far less than IE does (and I use several browsers all day for web app testing).

Of course, leave it to OmniWeb to ruin the cocoa speed myth, it sucks horribly. (Sorry Omni folks... OmniGraffe and OmniOutliner work very very well.. if that makes you feel any better... but the browser is just hideous. The CSS/HTML/JS support is probably worse than iCab's.) I'm not sure if cocoa is at fault, or some really shoddy HTML rendering code.

Then there's applications like Reason which use to run just fine under OS 9 but when ported to OS X (using Carbon, I presume) they kinda fall flat... same can be said for Photoshop 7, OfficeX, Illustrator 10, etc.

Now one could argue, that is the developer's fault!! .. Well sure, accept a lot of shoddy developers seem to use Carbon... so generally if I see a Carbon, particualrly one ported from the classic mac os - I really have to clinch my teeth and prey that it doesn't suck like the rest of the ones I have tried out.

I will say that I tend to have good sucess with the RealBasic Carbon apps.. not sure why. Perhaps those developers pay attention to little things like quality.

Wow shawn, you have about the exact opposite experience that I have had =) (With the exception of Office X & Explorer vs Chimera -- M$ apps have always sucked, and Chimera rocks the house!).

Actually, last I checked, Chimera's rendering is all done in Carbon. Once, for some silly reason, they were using ATSUI to render (still Carbon) but it was still much faster than it would have been in cocoa.

I use a lot of graphic applications every day and I can savely say that most graphic apps ported from os9 to carbon perform a lot slower than their OS9 counterparts.
But if you compare Create (cocoa) and Illustrator 10, both use antialiased graphics, but Illustrator redraws are a lot slower.
(But then again, I have a RiscPC strongarm@200 MHz from 1996 that redraws anti-aliased graphics faster than my Dual 1 GHz.)...

I sincerly hope that Apple will one day understand that speed IS a usability factor.

"What happens in a year when Apple releases an enhancement that [coupled with Rendezvous] will allow services from one machine to pass messages to another machine. Think Clustering."

Well then, you'd be right where COM/Windows was about five years ago. Think different!

strobe,

1. It would be much more appropriate to say that Windows behaves much more like NeXTSTEP than Mac OS 9 does. Remember, the Winblows 9x GUI was a (cheap, half-assed) ripoff of NeXTSTEP.

2. Cocoa apps tend to use POSIX file paths because Cocoa comes from a UNIX background. And we can't just tell everyone who's been using OpenStep before that they suddenly have to change all their code.

Another difference between Cocoa and Carbon: Cocoa is portable to other platforms (Linux, BSD, Windows, Solaris...). See GNUstep.

One area where Carbon beats the crap out of Cocoa is in AppleScript. The Cocoa AppleScript frameworks *suck*. Dictionary layout in a Cocoa app is seemingly random, (take a look at Mail.app's layout compared to Entourage's), and if you ask the developer, the answer is, "When it's fixed in Cocoa, it'll be automagically fixed in the app." Great, so I have to wait for a framework update to get a readable dictionary?

P-ew. No thanks. There's other issues, like the fact that getting the contents of selected text in a cocoa app is FAR harder than in a Carbon app. Creating a new message in a carbon email app is *far* easier than in a cocoa one.

Read Apple's AppleScript User list sometime, even Apple admits that much of Cocoa scripting sucks, and needs to be fixed. They're fixing it, but for right now, i run from scripting Cocoa apps.

Even the dev environments show this. Sure, i can get AppleScript Studio for free, but it *can't debug applescript*. The debugger simply doesn't work with the language. Oh joy, I have to use dialog boxes to trace my code.

For the couple of hundred dollars that I have to pay for Script Debugger, I get a far better AppleScript IDE, and I'll trade GUI development for a good debugger any day of the week.

john

Is Carbon threadsafe and/or thread-optimized?

Carbon apps (such as the Finder, Chimera and IE) seem much slower when doing multiple things (such as file copies, tabbed page downloads, etc) than Cocoa apps.

Do people porting from classic to Carbon have to rewrite in order to take advantage of OSX multitasking, or is stuff handled automagically?

Protected VM is nice, but a properly-threaded interface would do wonders for latency and perceived interface speed...

AHHHH, I am still not convinced! OK which should I learn, carbon, or cocoa. There is nothing here that point my mind in the right direction. It more seems like a bunch of bias comments!

Learn both. Simple.

Why is a procedural-based C API (Carbon) slower than a highly-abstracted OO-based Obj-C framework (Cocoa)?

From this benchmark http://oobench.sourceforge.net
A good C++ compiler can removed MUCH of the abstration penalties. Well Obj-C performance is even worse than Java. What can I say?

So, the only way Carbon is slower than Cocoa:
1. Poor graphics algorithm
2. Not hardware-accelerated
3. Delibrately made 2nd class by MacOSX to promote Cocoa.

I dislike MacOSX. Had they chose Carbon as their main graphical library. The C bindings to other languages would have satisfy majority of C/C++ programmers & minority of esoteric (Obj-C, java, etc.) programmers. OSX even supports X- programming. why all these libraries (Carbon, Cocoa, X, Swing, etc.)They will only consume more RAM.

Carbon is based on such obsolete approaches... there is not a single good Carbon application.. and look at who's switching all their apps to Cocoa? Apple! Even iTunes has horrible problems doing any sort of multitasking, apple's flagship product!

Boo! Carbon sucks!

Carbon is going to be faster. There's no late binding and run-time overhead that Objective-C and Cocoa will give you. And C++ is a better language than Obj-C because things like generic types (via templates--very efficient) and first-class support for exception handling (not thin wrappers around setjump/longjump.)