or Connect
AppleInsider › Forums › Software › Mac OS X › Carbon a no-show? (Oh chucker...)
New Posts  All Forums:Forum Nav:

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

post #1 of 32
Thread Starter 
Latest Apple Dev mailing has links to the preliminary pages for WWDC this year. Now, these are always sparse, and don't tell nearly the whole tale, *BUT*... I did notice something interesting.

http://developer.apple.com/wwdc/tracks/apptech.html

That page is the first draft of what will be covered in the Application Technologies track. Carbon is... barely mentioned. More to the point, the only specific mention of it in the top items is "Call Obj-C methods from a Carbon application" Furthermore, while it is listed in the teams that will have members there, it is *NOT* listed in the topics list below.

To add even more fuel to the conspiracy, one of the top items is "Use evolving APIs and development techniques for boosting application performance, code efficiency, and programmer productivity", which is the mantra we've been hearing regarding Cocoa for quite a while.

No judgement being made on my part here about the relative worth of the technologies, but I wonder if they're going to actually deprecate it for real?
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #2 of 32
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.
Download BARTsmart BART Widget, the best BART schedule widget for Mac OS X's Dashboard.
Reply
Download BARTsmart BART Widget, the best BART schedule widget for Mac OS X's Dashboard.
Reply
post #3 of 32
Thread Starter 
That's the direction I think it *could* ultimately take, but we'll see.

Interesting, if nothing else.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #4 of 32
"Kickaha" What does all this mean?

me is ignorant and couldn't be more clueless!
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
post #5 of 32
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.
post #6 of 32
Thread Starter 
No arguments on those - I suspect this portends Cocoa *becoming* feature-complete when compared to Carbon, or, at the very least, it becoming really and for true, the preferred API. ie, All future framework development will be in Cocoa, Carbon will stick around for legacy apps, but all new features will show up in Cocoa. The Obj-C-From-Carbon allows Carbon apps to access them, and they can migrate to Cocoa APIs on their own schedule.

Just my guess, I could be completely wrong, but I have a hunch that this is the beginning of Carbon being frozen.

Edit: Just noticed your mention of Carbon/CoreAudio - one of the things pointed out on the page for multimedia is... developments in CoreAudio. Curious.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #7 of 32
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.
post #8 of 32
Thread Starter 
PyObjC is what you want - it allows you to call into Cocoa from Python.

Cocoa currently handles C++ rather well IMO (it's called Obj-C++)... and of course Obj-C is a strict superset of C, so it has *always* been there.

You're not a bad programmer for not grokking Obj-C - it's a very different beast than C++ or even Java. In conceptual mindset it's more like Smalltalk than anything else, and it has its own unique little set of idioms that take some getting used to. Personally I love it, but I'm a dynamic OO junkie.

Actually, now that I think about it, if you think of it more like Python with a Smalltalk syntax for OO elements, and C syntax for procedural, you might be able to get closer to a zen state with it. I bounce between Python and Obj-C, but haven't actually ever merged the two, oddly enough.

And Apple didn't really have much choice on Obj-C when they bought (were taken over by) NeXT - all of NeXT's frameworks were written in Obj-C, and is what Cocoa derives from.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #9 of 32
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.
post #10 of 32
Quote:
Originally posted by Marvin
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.


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.


Quote:

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.

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.

Quote:


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.

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.

Quote:

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.

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.
post #11 of 32
Thread Starter 
Quote:
Originally posted by gregmightdothat
This is actually while I like Objective-C. Although Objective-C objects are dynamically typed, you still use C variables for serious data manipulation.

Yup yup. Unlike C++, Obj-C has a clean and clear distinction between objects and procedural code. Even the syntax is different, so you can immediately see what realm you're working in, and act accordingly. Love. It.

Unlike Java or Python, you can drop down into straight C (or heck, assembler) and get raw speed when you need it.

Best of both worlds, IMO.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #12 of 32
Thread Starter 
Quote:
Originally posted by kim kap sol
While this bit of news may surprise a lot of people...it doesn't surprise me one bit.

Well to be fair, and to stomp out any rumor fires, this isn't *news*, this is *speculation* based on some pretty flimsy circumstantial evidence.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #13 of 32
"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.
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
post #14 of 32
Thread Starter 
Oy.

Carbon and Cocoa are both APIs in MacOS X. An API is a suite of libraries and stands for their Application Programming Interfaces (or how you access those libraries).

Cocoa is an evolution of the libraries and technologies that came with the purchase of NeXT. NeXT's OS formed the basis for MacOS X in most ways, so it was natural to assume that Cocoa would be the one true API. Not so.

Carbon is an evolution of the original libraries shipped in Mac OS *prior* to OS X. They were designed to allow legacy developers from pre-OS X to continue using the system they knew.

Since then we've had this silly war between the Cocoa and the Carbon folks, each asserting that their system should be the One True API. (Personally, I much prefer the Cocoa API and think it has more potential in the long run, but others disagree. Of course, they're wrong. )

Carbon was *originally* advertised as *only* a legacy code assist, and the advice straight from Apple was "If you're writing a *new* app, go with Cocoa." A lot of people didn't listen, and we got stuck in this situation where both Cocoa and Carbon had to be supported by Apple long-term.

That may be changing. Maybe. Possibly. It's entirely possible that this means nothing.

For you, as the user, it doesn't mean much either way.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #15 of 32
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.
'L'enfer, c'est les autres' - JPS
Reply
'L'enfer, c'est les autres' - JPS
Reply
post #16 of 32
This means nothing to us users, nonetheless, it is with interest that I read what you guys have to say about it. Thank you.
post #17 of 32
ok a bit 'confussed' to say the least, I prefer tea!

spell not goood
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
Citing unnamed sources with limited but direct knowledge of the rumoured device - Comedy Insider (Feb 2014)
Reply
post #18 of 32
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.
"Slow vehicle speeds with frequent stops would signal traffic congestion, for instance."

uh... it could also signal that my Mom is at the wheel...
Reply
"Slow vehicle speeds with frequent stops would signal traffic congestion, for instance."

uh... it could also signal that my Mom is at the wheel...
Reply
post #19 of 32
Quote:
Originally posted by Kickaha
Well to be fair, and to stomp out any rumor fires, this isn't *news*, this is *speculation* based on some pretty flimsy circumstantial evidence.

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.
post #20 of 32
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.
post #21 of 32
Thread Starter 
Quote:
Originally posted by kim kap sol
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.

Was it basically never mentioned in the last couple years' worth of advance schedules too? As I recall, it's always been on an even footing with Cocoa in the tracks.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #22 of 32
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.
post #23 of 32
Thread Starter 
Yeah, that's my thought. It's obvious with things like Core* that they're trying to migrate to a single code base *eventually*, the question was whether that would be Core* with two wrapper APIs, or a unified system with a deprecated API, and a preferred API.

This *might* indicate that they're going with the latter, when it was pretty well assumed by many people that the former was the foreseeable future. Settling on a single API that has more legs for future opportunities makes sense.

The question is... how to do it successfully? We had Carbon as the 'fill-in' API that took on a life of its own, are they now getting to the point where, finally, they can start moving towards the original vision?
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #24 of 32
Quote:
Originally posted by Hobbes
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.
post #25 of 32
Thread Starter 
Just to add more information... the WWDC Session descriptions are up (or at least the ones that they're announcing publicly so far): http://developer.apple.com/wwdc/sessions/

Search for Carbon on that page.

One session: Carbon Feedback Forum.

That's it. Cocoa everywhere, that's it for Carbon.

Hmm.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #26 of 32
Interesting. It looks like the writing's on the wall.

I bet the Carbon Feedback Forum will be quite lively.
post #27 of 32
Thread Starter 
Well, either that or they're keeping secret the Carbon II .Xtreme sessions...
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #28 of 32
Quote:
Originally posted by Kickaha
Just to add more information... the WWDC Session descriptions are up (or at least the ones that they're announcing publicly so far): http://developer.apple.com/wwdc/sessions/

Search for Carbon on that page.

One session: Carbon Feedback Forum.

That's it. Cocoa everywhere, that's it for Carbon.

Hmm.

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.
--
[alloc init]
Reply
--
[alloc init]
Reply
post #29 of 32
Thread Starter 
It has a whole session devoted to it.

(Love the user name, btw)
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #30 of 32
Thread Starter 
Update:

Three whole sessions for Carbon (http://developer.apple.com/wwdc/schedules/):

Carbon Feedback Forum
Carbon Programming Hands-on
Cocoa for Carbon Developers

Aaaaaaand that's all folks.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #31 of 32
Leaked from a Vista Dev community board (of all places):

Quote:
Carbon, the set of APIs built upon Classic MacOS and used by most 3rd party high-profile Mac OS X applications, now allows Cocoa views to be embedded into the application. This could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications.

Lots more there too, but the above relates specifically to this thread.
post #32 of 32
Thread Starter 
HMMM..... interesting. Not so much a straight deprecation as a 'you can (and should) embed the Cocoa pieces whenever possible'. Nice migration path.

I'd love to hear why Carbon was almost MIA from the schedule.

Of course, I'd love to see a filled-out schedule.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Carbon a no-show? (Oh chucker...)