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

Posted:
in macOS edited January 2014
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?
«1

Comments

  • Reply 1 of 31
    xoolxool Posts: 2,460member
    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.
  • Reply 2 of 31
    kickahakickaha Posts: 8,760member
    That's the direction I think it *could* ultimately take, but we'll see.



    Interesting, if nothing else.
  • Reply 3 of 31
    irelandireland Posts: 17,798member
    "Kickaha" What does all this mean?



    me is ignorant and couldn't be more clueless!
  • Reply 4 of 31
    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 nightmare?it desperately needs to be reworked).



    Also, Cocoa's major niceties?Cocoa 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.
  • Reply 5 of 31
    kickahakickaha Posts: 8,760member
    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.
  • Reply 6 of 31
    MarvinMarvin Posts: 15,310moderator
    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.
  • Reply 7 of 31
    kickahakickaha Posts: 8,760member
    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.
  • Reply 8 of 31
    kim kap solkim kap sol Posts: 2,987member
    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.
  • Reply 9 of 31
    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.
  • Reply 10 of 31
    kickahakickaha Posts: 8,760member
    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.
  • Reply 11 of 31
    kickahakickaha Posts: 8,760member
    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.
  • Reply 12 of 31
    irelandireland Posts: 17,798member
    "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.
  • Reply 13 of 31
    kickahakickaha Posts: 8,760member
    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.
  • Reply 14 of 31
    gene cleangene clean Posts: 3,481member
    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.
  • Reply 15 of 31
    ipeonipeon Posts: 1,122member
    This means nothing to us users, nonetheless, it is with interest that I read what you guys have to say about it. Thank you.
  • Reply 16 of 31
    irelandireland Posts: 17,798member
    ok a bit 'confussed' to say the least, I prefer tea!



    spell not goood
  • Reply 17 of 31
    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.
  • Reply 18 of 31
    kim kap solkim kap sol Posts: 2,987member
    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.
  • Reply 19 of 31
    chuckerchucker Posts: 5,089member
    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.
  • Reply 20 of 31
    kickahakickaha Posts: 8,760member
    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.
Sign In or Register to comment.