Which Coding Framework for Mac OS X ? 334
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.
You also have Carbon (Score:5, Informative)
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;
Re:You also have Carbon (Score:5, Insightful)
Carbon only exists to support people who have existing Mac OS applications that they want to move to OS X.
If you're beginning, learn Objective C and use cocoa.
There is no reason to use carbon for new applications. You can access every API that exists in carbon from within cocoa apps and objective-c, but the reverse isn't true.
With Cocoa you get everything Carbon has, but with Carbon you don't get everyhting Cocoa has-- especially the superiority of Objective-C and the Appkit and Foundation frameworks.
Anything you really need to do, you can do in carbon, its just a lot harder.
There's no reason not to use Cocoa for Mac applications.
Native, native, native (Score:2, Informative)
Re:Native, native, native (Score:3, Insightful)
Re:native != better (Score:5, Insightful)
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.
Re:native != better (Score:3, Insightful)
Cocoa puts you in the MVC pattern, meaning that you have rather good portability if you decide to go to a different view-- just subclass your controler and tie it to the new UI.
Objective-C is portable because GCC is portable.
learning objective c (Score:5, Informative)
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.
Re:learning objective c (Score:3, Informative)
I agree, I used to program on the NeXTStep platform (my placement/internship company were typesetters, the native PostScript came in handy) and it is virtually (I may be completely wrong here, I havent touched OS X, let alone Macs ;) ) the same thing, just a tad older
With our NeXT systems, you could program in Objective C (being the staple diet), but you could also use C/C++ code as well if you wanted. It won't take to long to get used to (I've heard some peeps say that Objective C is more of a proper OO than C++, but I'm not taking any sides here!)... plus as a programmer, once you know the basics it is just a case of getting used to the semantics, syntax style and quirks of the different language you're learning. Good Luck!
Re:learning objective c (Score:3, Informative)
OpenStep and Cocoa, however, are virtually the same thing. OpenStep was a big revision of the OS and the API.
But all the same, I heartily reccomend using Objective-C and Cocoa, especially above the other options presented: Java and C/Carbon.
Re:learning objective c (Score:3, Informative)
Once you've mastered C-- which takes about two days, using nothing more complex than a copy of The C Programming Language by Kernighan and Ritchie-- you can learn Objective C using Apple's language reference, which is available for free on the web at this link [apple.com]. (Warning: 1.7 MB PDF) Apple also has a number of tutorials on Cocoa programming available on developer.apple.com [apple.com] that make for a nice, gentle introduction. You'll know Currency Converter inside and out in a matter of hours.
how easy is it to connect front end cocoa stuff like drawers, services access, etc to java backend services
Trivial. There's a full Java language binding for the Cocoa API. You can, in fact, write an entire graphical application in Java with the Cocoa API (using Interface Builder for the GUI, naturally).
As for your other questions, I'll defer to people with more experience than I have.
Re:learning objective c (Score:2, Insightful)
C, like any language, has its idioms and design patterns and these will take time to learn. Buying a book like K&R will help but I imagine there are more useful introductions to C. K&R is an incredibly terse, albeit a useful reference - and iirc it does not have much of the c library spelled out in detail)
In summary, C is great, but don't expect to be a master of it anytime soon. And anyone who claims they are a master after 2 days is not.
Re:The Master Of C (Score:4, Funny)
Re:The Master Of C (Score:2)
Now, if you're talking about the C standard library, or the various POSIX APIs, that's a different story. The various standard C APIs are numerous and bewildering. But the same can be said of any language/API combination.
Re:The Master Of C (Score:5, Informative)
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,
Re:The Master Of C (Score:5, Informative)
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.
Re:The Master Of C (Score:5, Informative)
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 [macdevcenter.com]
if you find you have objects deallocating prematurely and are losing track of yr reference counting, get the object meter [omnigroup.com] from omni group (makers of omniweb). there's a free demo license that works quite well for the budget-challenged.
Re:learning objective c (Score:4, Informative)
Coming from Java, you may want to use "Objective-C++" simply for the ability to declare local variables anywhere in your code. Straight C and Obj-C only let you declare local variable at the beginning of a block, but Java, C++, and Obj-C++ let you declare them anywhere in your method. Obj-C++ gives you a bunch of other stuff I don't even know about, but for me, all I care about is the flexibility with local variables. Simply use the ".mm" extension instead of ".m" for your source files.
Re:learning objective c (Score:3, Informative)
Just get any of the good Cocoa books like "Building Cocoa Applications or the Hilgress book.
They will teach you Objective-C in the early chapters.
Apple puts out a free learning Objective-C book with their development platform.
You don't need to waste time with C becuase you already know java and Objective-C is more like Java than C in use.
Learning C means learning a lot of useless pointer crap that you don't ever use in Objective-C.
I'd say, it will take you no time learning it, and the compiler will catch all the mistakes you're likely to make. (I came from Java, though I'd used C a lot in the past.)
Java is enough like C that you should have an easy time-- just get a cocoa book.
Seems like you answered the question yourself. (Score:5, Interesting)
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.
A, B, C, or NONE OF THE ABOVE. Not 'D'. (Score:2)
If you follow a sane strategy, and don't use Objective C OR Carbon C++ (and its associated event and I/O management cruft) to handle your application logic, I don't see what the advantage to Carbon is.
That is to say, if all your application logic is straight C++, and you're only doing UI and event integration in "Native" MacOS, why would you choose to use Carbon (which seems approximately as complex as Win32) instead of Cocoa?
Re:A, B, C, or NONE OF THE ABOVE. Not 'D'. (Score:2)
Mach isn't a NeXT idea; it's a CMU idea [wikipedia.org]. NeXT and Darwin aren't the only Mach operating systems.
Re:A, B, C, or NONE OF THE ABOVE. Not 'D'. (Score:2)
This, and other comments like it are convincing me that there's an axiom:
"Anyone who ends a sentence with the word "period" doesn't know what they are talking about, and the sentence in question is absolutely false, period."
Really. In my experience, all my carbon apps are slow to launch and Cocoa apps are sometimes slow to launch and sometimes fast to launch.
MY cocoa apps are very fast to launch because I designed them correctly. If you lump everything into one nib file your cocoa app can be slow to launch, but that is a problem with the programmer, not with the design of the app.
I'm not sure what causes Carbon apps to be so slow to launch, but then, I'm not claiming an absolute truth- just what I've observed. Period.
Re:WRONG - Carbon provides this too! (Score:2)
Apple was sure to optimize the Carbon APIs not only for compatability but because sometimes your project doesn't need to be Object-Oriented Cocoa style, Carbon will work just fine and just as clean. I am starting to think that some people (who aren't "in the know" with the Mac) confuse the Carbon set of APIs as analogous to running in Classic mode, which is entirely not true.
Cocoa all the way (Score:5, Informative)
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.
Re:Cocoa all the way - Mod Parent Up (Score:5, Informative)
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
There *is* a good reason for java cocoa (Score:2, Interesting)
I have a web-based app that I wanted to create a non-web GUI for (involved various file uploads and stuff that could more easily be handled via a native GUI). The server supports XML-RPC, but at the time, I didn't have an XML-RPC framework I could use from Objective C. However, I did have a fully functional commandline app that did it that I'd written in java.
So, I just fired up project builder, told it I was writing a java cocoa app, and spent a while getting the UI the way I wanted it, then just plugged in a couple methods to the controller to call the existing code.
Because this was my first OS X application, it was a learning experience as far as picking up the cocoa concepts and stuff, but it only took a day of me being home sick (and I felt pretty crappy, so I wasn't working all that fast).
The time I spent learning cocoa concepts was not wasted at all. I figured out how to build frameworks and get them into my application, so I had the stuff I needed to go full objective C. I *copied* the UI I'd already made into a new project, and pasted a lot of the code straight from the java app to the objective C app (mostly controller stuff). Of course, I had to convert the java cocoa calls to objc, but for the most part, that was it.
Moral of the story: If you intend to write a native OS X app, and you don't have all the parts you need in objc, but you do have most of it in java, do it in java! It was a good proof-of-concept anyway.
Let the application dictate the language (Score:5, Insightful)
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.
Re:Let the application dictate the language (Score:4, Informative)
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 [cocoadevcentral.com] for more info.
Nothing wrong with Objective C (Score:5, Informative)
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.
Re:Nothing wrong with Objective C (Score:3, Insightful)
Make no mistake - nobody's going to code the next operatig (sic) system in [Objective C].
Funny, that's just what Apple did.
Re:Nothing wrong with Objective C (Score:2)
Are you seriously claiming that the kernel of the OS is written in Objective C?
If it is, please tell me, as I'd be quite impressed.
AFAIK - the Kernel and Darwin are C, but hey, I'd like to know if otherwise.
Re:Nothing wrong with Objective C (Score:3, Interesting)
Re:Nothing wrong with Objective C (Score:2)
I've done a bit of hacking on the keyboard driver to rearrange my TiBook's keyboard. There's a fairly elegant way to patch things, all object-oriented.
You're sorely mistaken (Score:2)
Re:Nothing wrong with Objective C (Score:2)
But an "Operating System" without a kernel is NOT an operating system, and that's why RMS doesn't get any respect anymore.
Mozilla (Score:5, Interesting)
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
Re:Mozilla (Score:5, Insightful)
As a co-author and currently sole developer of a Mozilla component application, I feel I'm qualified to voice an opinion on this. (MOOzilla [www.moo.] being the application)
Mozilla is really damn cool. You can do some amazing things by combining existing Mozilla code with your application. For example, yesterday I discovered a way to dump an entire MOO/MUD session into an HTML file by using a function in nsContentAreaUtils.js. This was funky. It was not, however, exactly what I wanted, so I now need to write similar code myself. The point is that Mozilla is great...
But I can't see using it for anything that doesn't somehow relate to web browsing or networking. I know there have been efforts to do elaborate things like writting Office suites in Mozilla, but I don't think it's really feasible because the API availble through XPCOM is more geared towards this kind of web-based development. In MFC, for example, you have access to beautiful serialization and dynamic runtime creation and other nifty stuff that makes coding easy.
Re:Mozilla (Score:3, Informative)
As a matter of fact...
I have used MFC serialization in the most bizarre and difficult ways. In normal usage, adding new data into an existing set of serialized data is really, really easy. Just make sure that every object you serialize stores it's own version number when you write it it out. Increment the version number when you make a change to the serialization out, and pay attention to the version number when you're reading in the object.
If you're creating a new version of your application, say re-writting the code from scratch, it is easy to write a set of classes that can read old product files and convert them into your new object structure. In fact, I've even written code that re-writes the runtime dynamic class names in a serialized data file just so it can be read in by a new generation piece of software.
The ability to make compound documents with MFC is unbelievably sweet. I was part of a development team which created a single unified file format with a compound document architecture that was readable by 5 different pieces of software. Each piece of software had it's own slot in the compound document to write their own specific data out. I could derive my own classes off the base data classes, and they would be runtime created by the serialization when reading files. It was the sweetest little file system ever.
Could it be done with XML? Yes. Would I prefer to work with XML? In principle, yes. Did I suggest that we use XML for a world-readable data export? Yes. But management would prefer to write up contracts with other companies to share data reading specs. And sure enough, that worked, and our products sold. So MFC serialization was sweet from a programmer's point of view, and was practical from management's point of view.
Re:Mozilla (Score:5, Informative)
If you haven't looked at it closely, don't knock it. Take a look at Creating Applications with Mozilla [mozdev.org], from O'Reilly (of course.)
Mozilla != MacOS (Score:2)
Mozilla/XUL on OS X is hard to take. It reimplements the entire UI toolkit (and what it comes up with looks nothing like the Apple guidelines). It's also incredibly slow (as in, KEYSTROKE LAG in text inputs!). And unlike in Win32, where IE can hide in the background and leave you with something that looks like an application, in OS X you'll be literally running your application through the nightmarishly bloated Mozilla environment.
You're also kidding yourself if you think you'll wind up with something cross-platform. XPCOM doesn't magically make a C library compiled PPC Mach-O work on x86 ELF.
Don't get me wrong; I like the COM/DOM/C++ environment and have worked on teams that used it successfully. But right now I think it's mostly applicable to dynamic web applications (people put up with more in client/server situations).
Re:Mozilla != MacOSNowis (Score:2)
I recognize that xpcom components are not automatically portable, but they are a heck of a lot more portable than most similar environments. XPFE takes care of most of the nitty-gritty work necessary to make them portable.
Re:Mozilla (Score:2)
Greetings,
Don't overlook REALbasic (Score:4, Interesting)
Don't reject it out of hand just because it isn't a "macho" language.
I don't say it's the right environment for you. I do say you're being foolish if you don't at least take a look at it.
You can make a very good evaluation because REALsoftwarelets you download a version that is complete, and comes with full documentation (it produces time-crippled applications that only work for thirty days).
Re:Don't overlook REALbasic (Score:4, Funny)
Re:Don't overlook REALbasic (Score:2)
Re:Don't overlook REALbasic (Score:2)
QT can be the right solution (Score:3, Interesting)
But if you have a complex GUI, do take a look at QT/Mac [trolltech.com] from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.
--jeff++
Cocoa / Obj-C (Score:5, Informative)
Definitely, learn [apple.com] 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 [apple.com], you can completely abstract your UI [apple.com] from the core of your code.
Since you say you want to use the BSD layer, I suggest making a command-line [apple.com] 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 [apple.com] native IPC libraries [apple.com] in Mach. If you don't mind your code [apple.com] 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 [apple.com]?
Re:Cocoa / Obj-C (Score:2, Informative)
Also, O'Reilly's Building Cocoa Applications [oreilly.com] is excellent for the beginner, although I wish they would publish AppKit & Foundation in a Nutshell for a good off-line reference.
Some other good references:
Re:Cocoa / Obj-C (Score:3, Informative)
You can build tools in Objective-C, and GCC supports objective-C so objective-c itself should be pretty portable.
Its just the cocoa frameworks that aren't. (Though there are people creating an open source version of it.)
use Cocoa (Score:5, Insightful)
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:
How about Qt/Mac (Score:3, Informative)
I used gtk for a while and now switched to Qt. It is just wonderful. I can just recommend it to anyone who is willing to use C++/perl/pyth/ruby or so. It is pretty solid, and (wit exeption of the moc-precesser) very beautyfully designed. It is portable and available on Win/Unix/Linux/MacX.
I ported some of our apps to Qt/Mac. Well, I recompiled the Qt stuff and the porting was related to other parts.
Even though many people don't seem to realize, it Qt is fully GPL. The plain, good ol GPL. So if you project is GPL it is a very good choice. If not, you probably have the money to pay and it is still a good choice.
Cheers, Peter
Only on X11 (Score:2, Informative)
Qt is fully GPL.
Only when compiling for the X11 target, which requires Mac users to install XDarwin and Windows users to install Cygwin and XFree86.
Java Cocoa (Score:5, Informative)
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.
Depends on the needs [/METOO] (Score:3, Insightful)
If you are already a C++ expert and have no desire/resources to learn a whole new language, or you want to use a more traditional toolkit that's easier to port, or you are porting an app written for Windows or OS 9, use Carbon. It's essentially identical to the Mac Toolbox, with a few types changed and memory hacks replaced with accessors.
If portability is very important, use Java. OS X's implementation of the various Java GUI toolkits provides the Aqua interface automaticaly, as well.
It is possible to use all of OS X's native APIs (Cocoa, Carbon, and Posix) in the same project, if you really must. The libraries are already quite interdependent and any potential conflicts are noted in the documentation (i.e. don't use NSThreads and pthreads at the same time).
Don't discount Cocoa! (Score:5, Insightful)
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
I wouldn't say Java-Cocoa is worthless. (Score:2)
As far as the Carbon programming maybe it's the developer not the tool. I could try building my own house (by hand) but why when I couldn't frame a house to save my life? My framer is skilled in building and I am not. Same goes for Carbon programming, Adobe Photoshop seems to run just fine and it's a carbon app.
Use Cocoa (Score:3, Insightful)
Objective-C is a small, elegant object-oriented version of C. It's very easy to learn, easy to document, and easy to modify. Compared to the size of Carbon and Cocoa, this is absolutely the least important part of your framework-learning experience.
So here's the deal. Cocoa is an elegant, brilliant, clean and simple framework derived from the (rightly praised) NeXTSTEP/OpenStep libraries. Carbon is an evily patched hulking pile of OS9-compatible goo. The difference between these two libraries could not be more stark.
Apple's proclamations otherwise (made to make Adobe and Microsoft happy), Carbon exists for exactly one purpose: as a porting library for legacy code. The nastiness of Carbon lends some insight into the hideousness of developing for OS9, one of the reasons Apple simply could not get the Copeland project working.
Use Cocoa.
Comment removed (Score:5, Informative)
Might want to read this (Score:4, Informative)
Why not wxWindows? (Score:3, Insightful)
I have started using wxPython (Python bindings for wxWindows) as my primary development platform, and am quite happy with it. It enables me to develop my application on OS X, even though my primary target audience is using Windows. =)
Re:Why not wxWindows? (Score:2, Informative)
I've been using wxWindows for linux and windows for about a year now, writing diagnostic tools for our manufacturing plant (some very complex). I've needed to get down and dirty with process monitoring, threads, and IPC, and I can tell you, that wxWindows is great. I was able to write once in linux (my prefered platform at work) and just compiled it on windows.
As for the mac, I would imagine it's similar, but I don't have the experiece yet (just got my mac a month ago).
And the best part is, it's free.
Here's how I see it (Score:5, Insightful)
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.
Re:C# (Score:2)
C# is already dead. It would be stupid to write applications in it.
Nobody is going to support it because everyone knows that doing so puts them at the mercy of Microsoft, and microsoft has shown themselves to be both desirus of the entirety of the application market and also willing to undermine the ability of competitors to work on the platform. C# makes it really easy for them to do this.
COBOL has more of a future.
By default, I recommend Cocoa / Objective-C (Score:2, Interesting)
With Carbon you have to implement a lot of stuff Cocoa gives you for free. I still haven't seen a non-sample-code Carbon app with proper Unicode support. Then there are things that Swing apps just can't do. (And don't believe Sun's pluggable talk. You can't just plug in Aquaness without designing for Aqua.)
The Cocoa Java API feels like an Objective-C API anyway, so you might just as well learn Objective-C unless you already have Java back end code.
Objective-C is way cooler than C++.
what is wrong with objective-c? (Score:3, Interesting)
Along the lines of the myriad calls to use Qt... (Score:2, Informative)
...I'd also suggest taking a look at wxWindows [wxwindows.org]. They're open source, the results look very mac native (they have screenshots), and it seems to be very portable....having libraries for windows, most *nux (using GTK, Xt, or Motif), and macs, and maybe a few others. Oh, and it's c++ for those with an objective-c phobia, like me :)
I honestly don't know why more isn't done with this framework outside of those crazy python people. It looks good, and is completely free (both as in beer and speech), unlike Qt (not trolling, just stating a fact!)
suck it up, learn Obj-C (Score:2, Insightful)
However, Carbon is no fun, IMHO. It's just not as easy to work with as something like Cocoa or Swing.
Second, why do you say that Cocoa/Java is not well documented? Just look at developer.apple.com and read all about it... Besides, all Obj-C Cocoa APIs have equivalents in Cocoa/Java. So it shouldn't be that hard.
But, why use Java? Maybe you like it, in which case, go for it... But I think that if you have C and C++ experience you'll find Objective-C to be much more robust for Mac programming, simply because: 1) you can learn it quickly if you already know C/C++, and 2) you get a well thought-out API (Cocoa, formerly NeXT's AppKit) with access (both via Objective-C and via libc and other C APIs) to Mach, BSD, and Mac OS X specific goodies.
And, for the love of all that is good, pure, and holy, don't use Swing. It's disgusting. Someone needs to beat it into the ground and start from scratch. The only reason that I would see for using it (and, granted, it's a good reason) is for portability... But in that case, I highly recommend Qt (www.trolltech.com). It works nicely on Windows, Linux, and Mac OS X... Only problem is it isn't necessarily free. =(
Personally, I learned Objective-C in a couple of evenings after reading Apple's (formerly NeXT's) excellent book on Objective-C. It's available for download in PDF format from developer.apple.com.
So I say go for that, I'm sure you'll be impressed with the results you get.
Cocoa (Score:2, Interesting)
Carbon exists to provide a way for old codebases to run on OSX. Consider it only if you're already familiar with pre-OSX mac programming, and then only if you have a big, old codebase.
Java is useful for cross-platform server apps.
If you had done the least amount of research... (Score:2)
Carbon is old, and fastly deprecating.
Cocoa is "the" API to use, and you can intermix C and C++ code to your heart's content with it (eg. BSD code)
Cocoa/Java is considered crap, even by Apple (see Apple dev docs), and is not ready for prime-time.
Pure Java is alright, but doesn't give you access to BSD stuff.
In short: duh.
many choices, choose one which fits your style (Score:5, Insightful)
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.
Cocoa (Score:2, Informative)
The Objective-C language has got to be the coolest language I have ever used. I love being able to add a method like -encryptWithKey: to the NSData class without subclassing it.
The automatic memory management with -retain and -autorelease is great, too. Almost never have to worry about it.
Besides all this, you can use straight ANSI C code (and C++, too, in Objective-C++) right in the same source file.
In short, give Cocoa a look. If it doesn't meet your needs, try using one of the other solutions. The only thing I can come up with where you would need to not employ Cocoa is if you desire easy portability.
my experience (Score:4, Insightful)
I would not be scared of learning Objective-C--it is a very simple language and easy to learn, and its object model is very convenient. But in other ways, Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards. And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++. On the plus side, Cocoa is what Apple really wants you to use, and that's where they seem to be putting a lot of their efforts.
Cocoa using Java is probably in a certain sense "the best" programming environment for the Mac: it's modern, easy to develop in, and mostly safe. It's also pretty well supported. But it retains many of the warts of the Cocoa APIs and, as you observed, is not all that well documented.
With either Cocoa-based solution, you also have to ask yourself whether you believe that Cocoa has a future and whether it's worth learning it. I don't see much of a future for Cocoa, at least in its current form. Apple has made no moves to standardize it or open it up, so it is Mac only. Even if Apple pushed for more widespread adoption, they'd have to make big changes to make it palatable to industry, like adding precise garbage collection and better error checking to Objective-C, with the resulting changes to the APIs. An example of work in that direction can be found here [gerbil.org] (yes, that is "gerbil.org", but it's a site about programming, really).
Swing Java is probably the least hassle: it's well documented, it works very well on Macintosh, and you still get the native look-and-feel. It has modern resource management and modern layout management. Knowing Swing is useful and helps you on other platforms as well. And its object system is fairly similar to that of Objective-C. But some of the more advanced features have been buggy in the past (e.g., audio input, etc.). You can, however, combine Swing and Cocoa APIs, using Swing for the GUI and dropping down into native APIs only when Sun's cross-platform APIs fail you.
If you use one of the Java-based solutions but find the Java type system too constraining, you can use Jython [jython.org], a Java-based implementation of Python. You can choose to run it interactively or compiled. It's great for exploring the Cocoa APIs (or the Swing APIs).
Another choice you may want to consider is wxWindows [wxwindows.org]. Recent versions run very well on MacOSX and look native. If you want to see an example of an application written in wxWindows, take a look at Audacity [sourceforge.net].
I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.
Re:my experience (Score:3, Interesting)
That's a matter of opinion; I and many others would disagree.
And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++.
Not really. Objective C has no built in memory management (neither does C++), but it uses a reference counting system that works well enough that you rarely have to manually allocate or free memory.
I don't see much of a future for Cocoa, at least in its current form.
Apple does. Virtually all apps that come with Mac OS X are written in Cocoa and Objective C. iTunes and iMovie are Carbon, but that's only because they were designed to also run on OS 9.
python w/ pygame (Score:2)
Cocoa-Java Bridge (Score:2, Interesting)
Any Cocoa program can use any java class nearly transparently as if it were Cocoa! For some reason, Apple has hushed up this amazing feature. So, create a Cocoa app, and then use Java classes as necessary! Most of your code will run native, but if you need the VM, it'll be started for you.
This is what I used for my no-longer-being-worked-on front end to MySQL called CocoaSQL http://www.versiontracker.com/moreinfo.fcgi?id=10
I basically wrote a cocoa app using the mm.mysql drivers, very simple. The source code should be up there, if it isn't, let me know.
Good Luck, Max
COCOA COCOA COCOA! (and here's why) (Score:2, Informative)
Don't even think about Carbon. It's 18 years of evolution from a bitty-box API that was in Pascal.
Cocoa, on the other hand, is NeXTSTEP, and as any NeXTer can tell you, NeXTSTEP was the best operating system ever (at least the best API ever). It's amazing. Ten minutes with InterfaceBuilder and you'll be hooked. Where as most tools of this sort just give you some kind of data thingy that you have to interface with programmaticly using some magic codes, you can actually put OBJECTS in a NIB file, which will be unpacked at runtime, and automagicly referenced in places where you have references to them. They have these actions and connections. It's great.
Java is my favorite language (although recently Ruby has been fighting hard for that space), but I must say, the docs for Java-Cocoa are terrible. I gave up and learned ObjC.
That, inititally took about 45 minutes (I've done C++), but actually getting through the qwerks to where I could use the language well took 2 weeks or so. In a nutshell: If you are used to garbage-collection, you will hate ObjC. Period. It stinks. In almost every other respect, however, ObjC is a great language.
The Java documentation may have improved a lot since I ws reading it.
No, in short: Cocoa, cocoa cocoa. And Java if the docs are decent by now, otherwise Objective-C.
Cocoa with Objective C. Its the only way. (Score:4, Informative)
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.
Re:Don't use Cocoa (Score:4, Informative)
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.
Re:Don't use Cocoa (Score:4, Informative)
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.
Re:Don't use Cocoa (Score:3, Informative)
There was a session on this at this spring's developer conference. Even applications like TextEdit, which you'd assume would be pure Cocoa, considering the source, use a combination of Cocoa and Carbon code in them.
Your generalization is wrong, sorry.
Re:Don't use Cocoa (Score:4, Informative)
Re:Don't use Cocoa (Score:2)
"It's fuzzy-minded liberal thinking like that that gets you eaten." - Principal Snyder
The actual quote-- which is priceless-- is, "That's the sort of fuzzy-headed liberal thinking that leads to being eaten."
Just FYI. Please don't tell anybody that I watch "Buffy."
Re:Don't use Cocoa (Score:2)
Re:Best Framework for Mac OS X (Score:2, Interesting)
Re:Best Framework for Mac OS X (Score:4, Informative)
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.
Re:Best Framework for Mac OS X (Score:2)
Of course you're right-- who would know better, right?-- but you'd be surprised how many nontrivial Cocoa programs out there have only one class: Controller. They're basically straight procedural C programs with the Controller class in place of the main() function.
Re:What about QT? (Score:2)
Re:What about QT? (Score:2)
Re:What about QT? (Score:2)
--jeff++
Re:What about QT? (Score:2, Informative)
It runns just fine. porting from Linux to Mac? No, just recompile.
Re:Java -- no question about it. (Score:2)
Least-common-denominator approaches are good for nothing-- except grade-school arithmetic exercises.
Re:Java -- no question about it. (Score:3, Interesting)
Absolutely you can write good software in Java. I've seen it done, although I admit that I don't have the mad Java skillz to do it much myself.
But you can't write good software with Swing. Swing may be a fine user interface toolkit on UNIX, where there are no superior alternatives, but on a Mac, a Swing application-- unless it's specifically tweaked to use the Aqua look and feel-- is kind of an embarrassment. Java Swing apps run on OS X just fine, but they're unpleasant to use.
this post just makes me angry
I'm sorry. You get angry at strange things. Must have missed my post in another discussion about how disappointed I am that Mozilla is irrelevant; that post made lots of people angry.
Re:Speaking from experience... (Score:2)
You wrote:
C++?Objective-C is an extensions to C (like C++) but, for the extensions draws on Smalltalk for inspiration.
In addition you wrote:
Cocoa is an updated NeXT API.
Re:Speaking from experience... (Score:4, Insightful)
Spoken like a true C++ programmer. Objective C is not a "bastard child of C and C++;" in fact, Objective C and C++ share nothing in common at all except for the C language, of which both are supersets.
Objective C is a much simpler language than C++. Oft-troublesome C++ features like templates, overloading, multiple inheritance, virtual functions, and "friends" aren't implemented in Objective C. Mastering C++ can take years, while mastering Objective C is a task for a couple of afternoons.
Now Nextstep, that's a whole different ballgame.
No, it's not. Cocoa is essentially NextStep.
Re:Speaking from experience... (Score:2)
Re:Speaking from experience... (Score:2)
Re:I recommend . . . (Score:5, Insightful)
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).
Fink? (Score:2, Informative)
If it isn't true, explain to me why what are free utilities for Windows machines are $20-$30 extortionware for the Mac.
Which utilities that don't already have equivalents in Fink [sf.net] (i.e. d*b**n gnu/mac os x) are you talking about?
Re:JDK 1.4 (Score:2)
Sockets and threads; the spec says that if you have one thread waiting to receive on a socket you can cause it to stop waiting, and throw an exception, by closing the socket in another thread.
Now, if you do this to the native socket API you get difference results on different platforms. I may not recall all the details correctly but it's something like: it works on Windows; on Linux it works for UDP sockets but not TCP sockets; on Solaris it doesn't work reliably for either.
Fine, so the whole point of Java is portability, right, so the JVM somehow works round these differences in the underlying socket API, right?
'Fraid not quite right - there are some bugs listed against 1.4 which suggest to me that the JVM implementation of closing a socket in one thread whilst another thread is waiting on some sort of receive is not done cleverly at all, it just calls the native socket API and passes the differences up to the application, which is therefore not portable.
[I haven't done all the expermiments so some of the above is probably wrong in detail - I'd be grateful for any corrections from anyone with first hand experience.]
[So in fact the portability of Java is no better, in this respect, than writing the same thing in C direct to the socket API, except that it's probably harder to come up with nasty fudge workarounds in Java.]