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.
The ready-made integration offered by your two Java alternatives may not be useful for hardcore I/O anyways. How do you get a handle on an fd-based resource (/dev/bpf*, for instance) and then integrate the fd with your event loop?
My moving-forward plan has been to maintain my application logic in standard C/C++, and use Cocoa/ObjC to build UI (and nothing else) on top of that. Since most good BSD code is asynchronous, and Cocoa/CoreFoundation lets you control the event loop at the "select()" level, this works fine for me.
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.
I think you are missing a vital point. You can't just say "I'm getting into coding, is X or Y better?"
What is it exactly that you are writing? If you are writing a 3-D game, then the Java-Cocoa API is probably out. If you are porting your java-based massive application to Mac, than ObjC is probably out.
Basically, choose the one that fits your application's needs. If you just want to mess around though, go with Java-Cocoa just because it's more immediate.
Uninnovate - Only the finest in engineering.
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.
Several advantages:
- Easy cross platform. Your app will run on any platform Mozilla/Netscape run on.
- Easy development. Subjectively, development goes a lot faster than under a traditional framework.
- Something you probably already know: most people I know who program already know HTML and Javascript to some degree. From there, it's a very small leap to XUL and Javascript.
The major disadvantage is that it will necessarily be a little slower than a custom coded native solution. But who cares for most apps? With recent Mozilla versions, it's more than fast enough. Anyway, my $0.02Patrick
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
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."
Objective C is easy to learn and can be intermixed in the same source files with C++ (and obviously C). It's one of those "use the right tools for the right job" things. The GUI is most easily programmed with Cocoa using Objective-C, but if there's a nice library you want to utilize that's written in C++, there's nothing stopping you from using it.
Once you get comfortable with Objective-C, you realize that it is almost as easy to use as Java.
Now for the alternatives:
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.
Truthfully, Objective-C takes ~2 hours to learn. In fact, check out the first chapter of my (needing-to-be-updated) tutorial, Using Objective-C++ on Mac OS X here for a comparison of ObjC to C++.
:)
I used to be a C++ programmer, and then I spent some time playing w/ Cocoa, learning how the system works, and now, if Cocoa goes away, I think I'll quit programming. Its simple elegance and power is astounding, and freeze-dried objects in the NIBs are just cool. Just play w/ some of the tutorials (e.g. currency converter) before you discount it.
However, Cocoa-Java is kind of worthless. It's a kludge, and some of Cocoa's coolness comes from the weak-typing (id is slick--sort of a void* you can send messages to). Take a look @ cocoadevcentral, too.
Carbon, though, is klunky by comparison. Programming for that is just like programming for Windows/Linux...it's an API, and you can do nifty stuff, but it's not slick. Cocoa is slick. 'nuff said
Josh
You wrote:
:stares in disbelief:
um actually, stuff that is Free under the MacOS/MacOS X costs money on Windows for the same thing from another developer.
I use Windows at work and getting the same function as provided by a freeware Mac app costs money on Windows.
Mind you there are always exceptions to the rule.
My theory is that all Windows developers code fro money while some developers on other platforms code to give something back or just for the love of the platform (be it Linux, BSD, Mac, or something else).
Comment removed based on user account deletion
A well-designed application will separate logic from presentation, at least to some extent. Because the Cocoa API is most easily called from Objective C, programmers are free to write their logic in straight ANSI C, and use Cocoa user interfaces for the presentation layer.
The same is true of Java; in fact, many programmers may prefer this. You can write all your application logic in pure Java, and use Cocoa/Java code for the user interface. If the need ever arises to implement a different user interface toolkit, you can just replace the Cocoa/Java code-- which will probably be only a small fraction of your total code base-- with Swing/Java or whatever you please.
The important thing to remember, here, is that, on the Mac platform, native GUI applications are always-- always-- superior to non-native GUI applications. If you don't use native APIs for the interface, you're crippling yourself from the outset.
I write in my journal
I just started programming Mac OS X (I did a little Mac programming in the System 7 days and HATED it, since I was programming Unix at the time). But OS X is great.
I'm focusing on Cocoa myself, but here are some data points for you:
Objective-C is a lovely language. I looked it at back in the NeXT days and thought "cute, but it'll disappear and be replaced by a better version of C++". Well, Objective-C is still here, and C++ never got any "better". So you ought to learn Objective-C, it's very much like Smalltalk mixed with C, very elegant. I might start writing Linux and BSD programs in it. Also, it interfaces easily with the BSD side of Mac OS X. For instance, you want math libraries? You just use the standard math.h stuff! That's nice.
Don't use the Java Cocoa stuff. It STINKS. I think they just added it for a "bullet point". The documentation isn't as complete. It's very slow. Objective-C is a nicer language anyway, since it is dynamic. With Java you have to use a lot of reflection hacks to get the same results, not nearly as elegant.
Java DOES NOT (correct me if I'm wrong) compile to native code with ProjectBuilder. ProjectBuilder simply wraps a launcher around the java bytecode. If you drill down into the application package, you'll find the regular jar files.
The use of the Java Swing (non-Cocoa) stuff is simply to get your existing Java apps up and running fast. It took me just a few minutes to turn a Java program I wrote on Linux with Forte into a double-clickable (but slow) Mac OS application. Don't bother using this for new stuff. Your program might LOOK like an Aqua app, but it's really Swing.
Carbon let's you use C/C++. But it isn't a "compatibility layer" .. it's not obsolete or "going away". It's simply a cleaned-up version of the original Mac API. So if you choose this route, don't feel like you'll have to stop using it one day or something. I think Apple will support it indefinitely, alongside Cocoa.
Cocoa is a little slower than Carbon, because Objective-C is a dynamic language, and it has to decide things at run-time (like, say, Perl). Not a big deal these days, but raw speed is not a selling point of Cocoa GUIs.
AppleScript Studio: if you like applescript, you can write full applications in it. Just like on Linux you might want to throw together a simple Python script, etc., with a GUI. It doesn't hurt to learn applescript, especially if your Cocoa apps will be scriptable.
Interface Builder is just soil-your-pants awesome and let's you create, instantiate, and hook together non-GUI objects, right along with GUI objects. Also note that IB actually creates the GUI and other objects and serializes them to a disk file. It doesn't create any code or do any other tricks. And XML is used throughout for properties, etc..
So IMO your best choices are: Cocoa/Objective-C, or Carbon/C (or C++, blech). And I think everyone should learn Objective-C .. I'd like to see it used more for non-Mac stuff too.
Everything you need, including books and tutorials, comes on the Developer CD. Go through the Cocoa/ObjC tutorial.
Also note that if you sign up for the Apple Developer stuff, you have to agree to some pretty disgusting terms, including giving Apple the right to search your place of business on 24 hours notice. I shit you not.
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
There are two separate issues here: which GUI toolkit to use, and whch language to use. First, choose the GUI toolkit, and then choose one of the programming languages which can be used with that toolkit.
Most of the toolkits support multiple languages.
For new development, I'd strongly recommend using Cocoa with Objective C. Don't be afraid of Objective C! It's a very simple extension to plain old ANSI C. The additional syntax is minimal (unlike C++) and most of the code you write will be plain old C. Once you've learned Cocoa using Objective C, you may want to use it in Perl via CamelBones. But I'd strongly recommend using Objective C to learn Cocoa, otherwise you won't understand a lot of the reasons why things work the way they do. Don't use Cocoa with Java, unless you don't know C. And even then I'd recommand learning C so you can use Cocoa with ObjC.
If you want a plain old non-OO API, Carbon isn't all that bad. You'll need to get a good reference, as there are a lot of functions and types to learn about. (Whereas Cocoa is predictable enough that you can usually guess method names!) Or you can use one of the C++-based wrappers such as QT or PowerPlant.
-- Tim Buchheim
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?
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!