Carbon a no-show? (Oh chucker...)

Since one of the topics is using Cocoa from within Carbon applications, I could see Carbon being officially deprecated but still supported. All new development would focus on Cocoa since most of it would be available via Carbon hooks.

I don't know about you, but I'm feeling Cocoa runtime for Windows / Unix.

"Kickaha" What does all this mean?

me is ignorant and couldn't be more clueless!

I think it's more likely that Carbon's just plain not interesting anymore.

My first impression was to doubt that Carbon would ever be deprecated, since most programs are written in C/C++. But on the other hand, despite some oft-repeated rhetoric, Cocoa is generally just as fast or faster than Carbon when used appropriately (while calling methods is slightly slower, the simplicity of dynamic runtimes makes code smaller and more efficient).

Furthermore, Carbon deprecation wouldn't require an switch en masse to Cocoa, developers could just use new parts in Cocoa just where the pieces are needed.

There is a slight problem though: Cocoa isn't remotely feature complete. Most notably, the file API's don't handle niceties like alias and such. With the exception of Core Image and the limited NSBezierPath, all Quartz drawing is Carbon. Core Audio is Carbon (although I messed around with that this past weekend, and it was a nightmareit desperately needs to be reworked).

Also, Cocoa's major nicetiesCocoa Bindings and Core Data, aren't quite ready for primetime. Cocoa Bindings works for simple tasks (I pretty much only use the user defaults binding), it's totally too difficult to understand for stuff like outline views. Core Data's pretty much the same. It seems really cool, but I don't know how to debug it when it doesn't work. Because of that, even though it's probably just a feeling, I don't feel safe trusting anything to Core Data. I'm also curious if Core Data is the reason why Aperture's database is ridiculously slow.

I never really took to cocoa and coming from a C/C++ background, I was quite disappointed at how Apple went so head-strong into obj-c which was a relative unknown. It took me ages to get round the syntax. I find it really confusing.

I think lots of people have ended up using carbon but really neither it nor cocoa are complete. I think it would have been better if there was no carbon at all and cocoa just handled C/C++ better.

It's odd though, pretty much any good developer I speak to say that obj-c is a great language. I think I'm just a bad programmer for not seeing it.

I just wish they'd take something like Python and make it so you can compile the code to be as fast as a C-based language (I think psyco is supposed to do this but it's not on ppc - maybe Intel Macs though). That way, you can run/debug apps in real-time through the interpreter and compile at the end for performance. That would be RAD for sure.

Python is probably my favourite language right now. Clean language that enforces code structure and object oriented and available on all platforms. If Apple had added some advanced JIT compiler like psyco, they could maybe have gotten performance equal to or better than obj-c and that would have made cross-platform APIs like core graphics etc much easier as they could be loadable modules. Also, with the real-time interpreting, it could have been used in web APIs so no need for javascript or php. The world's a much better place when everyone speaks the same language.

While this bit of news may surprise a lot of people...it doesn't surprise me one bit.

There's no reason why the best of both worlds shouldn't be merged into a single uniform framework. Apple will then be able to improve a single framework instead of two.

Objective-C actually is about as old as C++ (C++ won because the ObjC runtimes were so bad back then). NextStep (aka Mac OS X) was most programmed in it, so Apple definitely didn't go headstrong into it.



Cocoa was built with Objective-C in mind. A lot of Cocoa *can't* happen in plain C++ (only in Objective-C++) because unlike C++, ObjC is dynamic and depends on the ObjC runtime. The way things went had to happen.


Not at all. It took a bit of programming in Objective-C, a lot of progamming in C++, and a lot more Objective-C before I realized how amazing it was.

If you wanted to spend some time with it (which I wouldn't recommend since Python seems to work for you), you'd see its advantages. Python has a lot of these same advantages.


Python will probably never be able to get quite as fast as C for processor intensive. Every object in Python is dynamically typed (as opposed to C which uses static typing). So while a lot C instructions map 1:1 to a processor instruction, no Python instruction, even simple arithmetic, can do this. So while Python is fine as a scripting language, it doesn't get low enough for stuff like data processing.

This is actually while I like Objective-C. Although Objective-C objects are dynamically typed, you still use C variables for serious data manipulation.

"To add even more fuel to the conspiracy, one of the top items is "Use evolving APIs and development techniques for boosting application performance"


"Kickaha" What does all this mean? What's the conspiracy part about? I switched last year, and i'm new enough to computers in general.

It's better to not understand it anyway; then you get sucked in into conspiracies and mini-wars between Cocoa and Carbon apps when all you wanted was a cup of java... I mean, coffee.

This means nothing to us users, nonetheless, it is with interest that I read what you guys have to say about it. Thank you.

ok a bit 'confussed' to say the least, I prefer tea!

spell not goood

If this turns out to be true, it could meen good things for Mac developers. More time would be spent working out the bugs, and coming up with cool new features (Cocoa bindings and Core Data) in the "one true" api.

I agree with Kickaha 100% about how well Obj-C handles being a multi-paradigm language. You can tell immediately if you are using procedural C ( executeMyFunction(); ) or OO messaging ( [object performMethod]; ). I love the syntax, and dynamicism of Obj-C. Also I don't think performance is that big of an issue with Obj-C. If you need to, you can always forgo the messaging goodness and drop straight down to C functions in performance critical areas.

Yeah...after actually looking through the WWDC links, I'm not so sure Carbon is getting less attention. It's getting just as much as the last couple years, IMO.

Since I'm being mentioned in the topic , I figured I'd just come by and clarify that I personally have little sympathy for Carbon. I just see why it's there, and I continue to feel that it has reason to exist (most especially for cross-platform apps with horrible separation between front-end and backend, like ChizenCoStuff). That said, I think everything relevant has already been said in this thread.

It's already possible to mix Carbon and Cocoa APIs, if you're careful, right?

Focusing on Cocoa and depreciating (but not breaking) Carbon seems like the next logical step to improve OS X development.

Yes. You don't even have to be 'careful', it's pretty easy.

The only problem is that you need to compile using Objective-C (for C applications) or Objective-C++ (for C++), and I'm curious if as to how this effects cross-platform compatibility.

I'm assuming if you set up a WIndows IDE to interpret ".m" (ObjC) and ".mm" (ObjC++) files as C and C++ files, respectively, and set the precompiler to ignore any ObjC code, you should be fine, but I've never made a Windows program.

Interesting. It looks like the writing's on the wall.

I bet the Carbon Feedback Forum will be quite lively.

I noticed that too. As several have said, it does seem like the next logical step. A single (or at least overwhelmingly-paramount) API could be a good thing. I hope this means QTKit will be maturing rapidly.

Leaked from a Vista Dev community board (of all places):


Lots more there too, but the above relates specifically to this thread.