Which Coding Framework for Mac OS X ?

DrStrangeLoop asks: "I am in the progress of getting into coding for Mac OS X, and I am wondering which GUI framework/language i should focus on. Apparantly, there are at least three options: the Cocoa Objective-C API [I don't want to learn Objective-c, but it seems that's how Apple wants me to code], the Cocoa Java API [gets compiled to PPC binaries, lots of APIs available [think Google], but absolutely no decent documentation to be found] and Swing Java classes [look 'n feel of Cocoa, but portable]. However, the most important feature for me is a clean and easy IPC with BSD layer processes. I figure sockets will work with all options, but what about the other mechanisms? Any suggestions?" Update: 10/13 22:08 GMT by C :For those curious about the Cocoa/Carbon debate, you can find an article that discusses this very issue, here. Thanks to the folks over at Freenode's #macdev for providing the link.

Comments

Sockets and Java

[Tim Ward]

If you want to make non-trivial use of sockets then there are plenty of things you can't do in Java anyway. Even if you find that Java can do what you want to with sockets you may find that it's not portable (particularly if you are combining sockets and threads).

Re:You're sorely mistaken

[Ageless]

Consider me corrected. My deepest appologies for offending you so deeply.
Dickhead.

Re:Best Framework for Mac OS X

[BitGeek]

What the hell? I thought Ambrosia was a quality place but this is pretty silly:

but like an OO framework, you must design your object hierarchy well ahead of time.

You should check out XP-- Extreme Programming. Its an excellent methodology that works fine with OO development. Its quite trivial to refractor your code when your project changes direction.

I'd say spending time designing your object hierarchies before you start programming is an example of *bad* development process, not good, even though I used to do exactly that same thing.

There is also a rather serious learning curve for Cocoa,

True, though it is significantly less of a learning curve than you have to deal with for Carbon. Cocoa re-uses objects a lot, whereas every Carbon API has a whole new set of data structures it takes as parameters, etc.

The learning curve is much lower for Cocoa than for Carbon. (And consequently, development is much faster in cocoa as well.)

and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.

That's just silly, unless your idea of "xplat" is crossing between OS X and Mac OS. But OS 9 is dead and I don't think people are really writing apps to support it. As for going from OS X to windows or linux, you have FAR MORE xplat possibility with cocoa-- first off there's cocoa-java, but even if you use objective-c There is work on an open source cocoa called gnustep. I'm aware of no xplat carbon frameworks, let alone superior ones.

Most of the major applications for Mac OS X are written in Carbon, and will continue to be.

That's just crap. Most of the major applications written for OS X are written in Cocoa. The only carbon apps are ones that started on OS 9 and were ported.

IF you're porting an app from OS 9, sure, use carbon. But if you're starting from scratch, it would be stupid to not use cocoa.