Slashdot Mirror
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.
Carbon is a good API to begin with. You can use C++ or C and access all the nice GUI of OS X.
.NET == Cocoa
Cocoa just makes things a lot easier.
I like to think of it this way (though technically its wrong, its a nice way to think of it): Win32 == Carbon;
To be honest, I'd say get over it and learn Objective C. For an experienced programmer it won't take you long to get to grasps with the basics of Objective C, and Cocoa is really easy to work with. Who knows, you might even grow to like it :) At first I thought Objective C was weird, but now I really like it.
Get a beginners book and work your way through it. I recommend Cocoa Programming for Mac OS X by Aaron Hillegass, published by Addison Wesley, ISBN 0201726831. This seems to be what most people learn from.
As someone who grew up around Macs, and then moved to NeXT, I'd have to say that if you know C, and understand OO principles (prefferably in the Smalltalk model, not C++), then you can pick up Objective-C in an afternoon. It's really just some extensions to C. Carbon is a great set of APIs if you've got 10 years of Toolbox experience on the Mac, but otherwise, it's much harder to learn the ins and outs.
Cocoa, because of it's past with NeXTstep, has a lot of emphasis on rapid-prototyping and dynamicism. Lots of delegation, lots of easy stuff to do to get an effective solution. As for Java, I'd have to follow Aaron Hilldegrass' advice... don't. Not on the Mac, not unless your goal is cross-platform. If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason.
Having written nearly identical programs many years ago for Mac, PC and NeXTstep, I'd say this. Mac and PC (Mac = traditional Toolbox on OS7.x) and Win32 are roughly equivelent to get the work done. Different, but one isn't necessarily easier. The NeXTstep app was implemented in 1/3 of the time, and that included me learning NeXTstep.
While it is true that the Carbon framework exists, it doesn't give you access to the full capabilities of Quartz/Aqua ..
.. If you have basic C skills, you should be able to learn it quickly.
Carbon was designed to ease the porting of old OS9 apps to OSX, and AFAIK is meant to vanish.
You'd better use Cocoa and learn ObjC
My two cents.
I love C++, templates, and think nothing of derfrrencing a pointer to a vector of objects that are stored in a crazy containter that I cobbeled together last night while high on cough syrup and mountain dew:
However -
Objective C kicks ass for GUI apps. It's easy to learn, and hides some of c's rough edges, and it's fast to compile. Make no mistake - nobody's going to code the next operatig system in it - but for GUI apps, take this good tool and run with it.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
The above poster hit the nail on the head.
Now, for my own two cents regarding Java+Cocoa: Don't do it. Some friends and I programmed a Jabber-based instant messenger in Java and Cocoa before OSX was officially released. Working with the beta frameworks was a nightmare, for one simple reason: Nobody else was doing anything with Java and Cocoa. To my knowledge, there are only a handful that work with it now.
Like other posters have said, if you're just starting out on a platform, get over your fear of learning a new language. Objective C + Cocoa on OSX and C# + Windows Forms on WXP are the way to go. Also, Carbon, like MFC on Windows, is only really useful if you've got a lot of experience with the older Mac operating systems. There's a lot of cruft in there that's not really necessary and can be a pain to learn. You should find yourself developing a lot cleaner code a lot faster if you take the time to learn the newer tools available.
Have fun. =)
Obligatory resume (on topic because it lists the project!... riiight): http://www.cs.hmc.edu/~awooster/resume.htm
Definitely, learn Cocoa and Objective C if you can, just for the experience of realizing how much better it is that most of your other choices. With InterfaceBuilder, you can completely abstract your UI from the core of your code.
Since you say you want to use the BSD layer, I suggest making a command-line version of this core code first (you can do this in C or C++), since this will be immediately more portable to other Unices. Once that is done, tying that code in with the UI you build in InterfaceBuilder is simple.
Also, there are some pretty interesting native IPC libraries in Mach. If you don't mind your code being tied to Mach, you should check that out as well.
Oh, did I mention that Apple's developer tools and documentation are free for download?
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
All that said, I would strongly recommend you take the time to learn ObjC Cocoa. I use Java Cocoa when I am grafting a Cocoa UI onto Java code, but ObjC is still faster (though the gap is narrowing) and I still honestly believe the language is still a bit more productive due to things such as Categories, Smalltalk-style method names, and other things. If you know C and Java and are familiar with the concepts of reference-counted garbage collection, learning ObjC will take you the better part of a morning.
Carbon and Cocoa are merely two APIs that allow you to do the same thing. Carbon is procedural, Cocoa is object oriented.
Many things are easier to prototype and get your initial code up and running in Cocoa, but like an OO framework, you must design your object hierarchy well ahead of time.
There is also a rather serious learning curve for Cocoa, and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be. Cocoa is a very cool OO framework, but it isn't right for every project, and the misinformation you're spreading is doing no one any good.
Comment removed based on user account deletion
Check out the article Introduction To and Experiences With Mac Cocoa from Kuro5hin.
If you haven't looked at it closely, don't knock it. Take a look at Creating Applications with Mozilla, from O'Reilly (of course.)
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
The difficulty of learning a language has little to do with the number of keywords it has. It is more a matter of how those keywords (and operators) are used together to enable programmers to do things. C is not that hard but in some cases it can get complex compared to other languages (even if those other languages have more keywords). Pointer arithmetic is one area in which many people struggle. Especially if you come from a programming language (like Java, ...) which doesn't have that.
C++ adds a number of keywords to the C language but not that much. Even so it is a highly complex language with lots of special constructs and exceptions.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
Um, no. Carbon is a transitional API, designed to make it easy for OS 9 apps to migrate to OS X. It's not bad, but it's procedural and requires you do to tons of stuff by hand that Cocoa gives you for free. If you're writing a new Mac OS X app, there's very little reason to use Carbon.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
If you are porting your java-based massive application to Mac, than ObjC is probably out.
That's not necessarily the case. Cocoa can (mostly) transparently manipulate Java objects from Objective C. See here for more info.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
There may be exceptions, however. Perhaps, for instance, the Cocoa QuickTime classes are wrappers around the Carbon classes. Since I haven't done any QT programming at all, I'm merely speculating.
There ain't no rules here; we're trying to accomplish something.
Re C and pointers:
;
;
Understanding pointers is a challenge for many C newbies. It helps if you remember that a pointer is just a number, usually a variable but sometimes a constant, which represents an address in memory. It helps even more if you can remember that that address in memory is just an offset from the start of the memory (note this only works on architectures with flat addressing; it gets a bit hairier on, say, DOS).
Since C is a pass by value language, passing a pointer (or anything else) means passing a copy of a value. In the case of a pointer, that means a copy of the address, so now both the caller and the called function know that some memory exists, and can (in the abscence of const) modify it.
Since the pointer is just a number, it can be added to. Adding to a pointer actually means that the address is incremented by the amount of the addition times the size of the thing being pointed to. In other words, the compiler takes some pains to ensure one is alsays pointing to the start of what should be an object, and not within the guts of the object. So if I declare a a pointer to a 2 byte sized object, adding one to the pointer will point me to the next two byte oject in memory, and not to the second byte of the first object.
Naturally, the programmer must allocate the memory to be pointed to. The pointer is merely an address, it's not the memory being addressed. Declaring a pointer gives the programmer a place to write the address down; it does not create the mmemory: the fucntion call malloc ("memory allocate" ) "creates" the memory.
I beleieve the OP noted he came from an assembly background, which means that he's used pointers (untyped ones at that) so it may be less of a challenge.
The other C pitfalls for the unwary are the declaration structure, and (related) to this, the way arrays are handled. Several primers exist on decoding declarartion syntax; in a nutshell, declarations should be read from the inside out, left to right until a right parenthesis forces reading right to left. The declarartion:
int ( *f )( char )
is read "f is a pointer to a function taking a char argument and returning an int.
In C, arrays are not first class objects, and so when passed to functions they "decay" to pointers to the first element of the array. An array name can be treated like a pointer, and indexing into an array is defined by the language to be exactly equivalent to dereferencing an array plus the index:
Given
char array[ 4 ]
array[ 0 ] is just *( array + 0 ); and array[ 3 ] is just *( array + 3 ). array[ 4 ] is *( array + 4 ) and is an illegal (well, undefined) dereferencing of the "element" one past the end of the array.
I have said too much for a post, so I'll end now. The point is, as long as one remembers a few key ideas: pass by value, pointers are numbers for addresses, and declarations need to be read inside-out, C is rather straigtforward.
Opinions on the Twiddler2 hand-held keyboard?
IF you already know C then learning Objective-C will take a week or two. If you know C++ or Java, then learning Objective-C will take a day or two.
Cocoa is, bar none, the best environment to develop applications under, on any platform. Therefore, if you've already chosen the Mac platform for your App, then use Cocoa.
Carbon is there fore backwards compatibility. Some parts of the OS are still carbon, and carbon and cocoa have been "toll free bridged" in places so you can use data structures interchangably. but it is much slower to build an app with carbon than cocoa.
So here's the simple way to answer your question:
1) IF you simply must use Java, or want to eventually run on multiple platforms, use Cocoa-Java (Which is well documented. Get Cocoa Browser to get easy access to the docs.) Use any Cocoa book to learn how to write in cocoa-java, just use the Java APIS instead of the Objective-C ones. Though Java isn't perfectly supported and Objective-C is recommended if you don't HAVE to use Java.
2) IF you have a large application ( greater than 10,000 lines) then it may be better to use carbon. A huge app, like photosohop, it definately makes sense. but any small application would be better off with rewriting the UI using the Appkit and Objective-C and just bringing over the calculation and graphics stuff from the previous version as-is. After all, Objective-C and C code (and even C++ code and Java) can be intermixed.
3) You should never start a new application using Carbon. Carbon is for backwards compatibility. IF you're starting a new application, use Cocoa and you'll save so much time with the superior cocoa apis that the time it took to learn them will be more than made up for.
I had a Java application that I wanted to bring to Mac OS X. I started down the path of Cocoa-Java and quickly realized that objective-c was recommended, so I checked it out and discovered even the fact that I was learning a new language, as well as a bunch of new frameworks, I was getting a lot more work done faster using Objective-C and Cocoa than I have in the past with Java.
Carbon is there for backwards compatibility when it doesn't make sense to rewrite the app. Cocoa-Java is there when you have a JAva app you want to migrate. But Cocoa with Objective-C is the clear, definite, best way to go under Mac OS X.
And anyone who's taken the time to learn it will tell you that it is far superior to the alternatives.
I dread dealing with Carbon APIs now as they invariably turn into time sinks where it seems to tkae 4-8 times as much effort to get something done as it would if there were a cocoa api for the area in question.
Go Cocoa/Objective-C.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
in obj-c memory mgmt is much better handled. when you make an object a "reserve" is put on it. when yr done with the object, you "release" it. you can add as many reserves as you want and release them when you wish. when the reserve count finally reaches zero, the object is deallocated. brilliant!
the skinny on obj-c and memory is here
if you find you have objects deallocating prematurely and are losing track of yr reference counting, get the object meter from omni group (makers of omniweb). there's a free demo license that works quite well for the budget-challenged.
2 1337 4 u!