macOS Carbon and Cocoa. Your opinions.

[bousozoku]

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]

<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]

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]

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]

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]

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.

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]

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]

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]

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]

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]

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]

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]

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

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.