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

You also have Carbon

[akac]

Carbon is a good API to begin with. You can use C++ or C and access all the nice GUI of OS X.

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; .NET == Cocoa

Re:You also have Carbon

[Anonymous Coward]

One thing to consider with Carbon is that keyboard navigation in open/save dialogs is broken (right now). However it works fine in Cocoa. Your users may prefer a Cocoa app for that reason....

Re:You also have Carbon

[Goalie_Ca]

Really!? That's odd!

Re:You also have Carbon

[Anonymous Coward]

Carbon isn't worth bothering with if you are coming new to the platform - it's primarily for porting of legacy OS9 code to OSX whilst giving the ability of dual-platform (OSX native and OS9 via CarbonLib) binaries. Admittedly the HIT (Human Interface Toolbox) has some nattier controls within Carbon that have yet to make it to Cocoa (and vice versa), Carbon isn't future proof, relying on a lot of 32-bit structures whilst OSX is migrating to a 64-bit platform if the IBM GPUL comes on track in 2003/2004. Apple themselves recommend Cocoa to all *new* developers, so don't go near Carbon wholesale unless you know what you are getting into. You can still use Carbon technologies (such as QuickTime) from within Cocoa, so you are not losing out, and Objective-C is actually easy to pick up (only 7 changes/additions to ANSI C) and brings very legible code as all arguments are labelled. I picked it all up in a day or two and have written a fair number of complex apps for my company since.

Re:You also have Carbon

[BitGeek]

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.

Re:You also have Carbon

[Anonymous Coward]

since nobody actually uses a mac, i would go with the Java.

Re:You also have Carbon

[Anonymous Coward]

Try it first in TextEdit, which is (mostly?) Cocoa (to see how it is supposed to work), and then in Explorer, which Carbon. You'll find that in a Cocoa app, once you've shift-tabbed into the column-view files list, typing the first letter of a file or folder will take you there. Arrow keys move you up and down in the hierarchy. In the Carbon apps, though, typing a letter seems to have random effect. Very annoying....

Re:You also have Carbon

[akac]

Actually - to all the people who say that you should use Cocoa if you're new to OS X - thats not completely true. I prefer Cocoa myself. But if I was to write an app I meant to be cross platform between OS X and Windows or Linux, then Carbon MAY make more sense since I may be able to reuse the C/C++ code there a lot easier. Of course, you could write your backend in C/C++ and use Cocoa for just the front end. And that would work if you have an app that is in the design stage. But if you are porting apps already designed that intermix frontend with backend (like most apps do unfortunately), then Carbon makes more sense - its closer to Win32 programming as well.

Re:You also have Carbon

[Anonymous Coward]

> There's no reason not to use Cocoa for Mac applications.

Unless you also want to tap into the legacy market -- there are still a lot of OS 8, 9 machines out there....

Re:You also have Carbon

[Cajal]

I'm not sure that I agree than Carbon will make your app easier to port. There is an open-source, cross-platform reimplementation of most of Cocoa called GNUStep, which is based on the old OpenStep spec (just like Cocoa). Using GNUStep you can run the same (or very similar) code on, say, Linux and OS X. See GNUMail.app for an example. Here is a screenshot of it running under Mac OS X, and here is a pic of the same program running on Linux via GNUStep.

Native, native, native

[Clock Nova]

I'd go with Cocoa. The more native, the better.

Re:Native, native, native

[akac]

Though I prefer Cocoa, Carbon is just as native as Cocoa is.

Re:Native, native, native

[Anonymous Coward]

Go Cocoa & C++!
Use the ObjC-C++ front end to gcc: http://developer.apple.com/techpubs/macosx/Release Notes/Objective-C++.html

Don't use Cocoa

[jpmorgan]

While Apple wants you to use Cocoa, they're provided a more typical C/C++ API called Carbon. I suggest you use that- everybody else does. :)

Re:Don't use Cocoa

[WoofLu]

While it is true that the Carbon framework exists, it doesn't give you access to the full capabilities of Quartz/Aqua ..
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 .. If you have basic C skills, you should be able to learn it quickly.

My two cents.

Re:Don't use Cocoa

[Fuzzle]

Yeah, it supposed to vanish. And it appears that with every update, some Carbon apps just break or start acting odd. I would recommend going completely native with Cocoa. It seems to create much better apps, and takes advantage of all of the extremely cool things that aqua has to offer. Not that Carbon is a complete dud, but Cocoa is the more technologically advanced piece.

Re:Don't use Cocoa

[Twirlip of the Mists]

Um... no, "everybody else" doesn't use Carbon. The Carbon and Cocoa APIs are both used pretty widely. Older applications that were written for the pre-OS X Mac OS Toolbox are usually ported to straight Carbon, because it's easy on the developers. But new applications often use a combination of Carbon and Cocoa to implement different OS features.

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

[zephc]

FWIW, the ObjC app framework was rewritten basically as a Carbon wrapper, unlike the older NeXT versions. So basically all the AppKit objects/methods are callling Carbon.

Re:Don't use Cocoa

[bnenning]

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.

Re:Don't use Cocoa

[Twirlip of the Mists]

Way, way off-topic, but your sig is wrong. You wrote:

"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

[bnenning]

Thanks for the tip. According to Google it's actually "wooly-headed" instead of "fuzzy-headed". Sig updated, and your secret is safe with me (although possibly not with the other million readers).

Re:Don't use Cocoa

[Twirlip of the Mists]

ACK! Of course, you're right. Who can forget Armin Shimmerman saying "wooly-headed liberal thinking!" Thanks for correcting me.

Re:Don't use Cocoa

[jimbolaya]

Not quite. Both Cocoa and Carbon libraries call a lower-level C library called Core Foundation. Both Carbon and Cocoa could be roughly considered wrappers around Core Foundation, but I wouldn't call Cocoa a wrapper around Carbon.

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

[Aapje]

This is just FUD, there isn't a lot that you can do in Cocoa, but not in Carbon (or vice versa). More and more they are just becoming two representations of the same basic API's. In fact, often enough Cocoa calls Carbon to do its thing.

BTW, as long as Photoshop and Word aren't rewritten (yeah right!), Carbon won't vanish.

learning objective c

[Dougal]

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.

Re:learning objective c

[davesag]

i am a long time java developer who has never done any c is his life. i went from 68k assember to java via ada, 4d and stuff like lingo and javascript. what books would you recommend for java programmers wanting to learn Objective C and Cocoa? how easy is it to connect front end cocoa stuff like drawers, services access, etc to java backend services. can rendesvous and jini map together? can one write an osx preference pane using java?

Re:learning objective c

[T-Kir]

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

[Twirlip of the Mists]

To learn Objective C, start by learning C. Objective C is just a superset of C; most of what you'll be writing will be pure C code.

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. (Warning: 1.7 MB PDF) Apple also has a number of tutorials on Cocoa programming available on developer.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

[RevAaron]

The NeXTSTEP API is quite a bit different than Cocoa. They're both Objective-C, use MVC throughout, and share many of the same class names, but the API is a lot different.

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

[jimbolaya]

Knowing Java will give you a big head start, since it's syntax is also based on C. There are numerous differences, to be sure, but I don't imagine you'll have a hard time. Probably the trickiest things for a Java developer who has never used C will be pointers, and header files, and of course, memory management. Obj-C uses reference counting, which is lower-maintenance that C or C++, but not nearly as easy as the garbage collection of Java.

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

[sweetleaf]

This is truly absurd. You will _not_ be a master of C in two days. You will be the programming equivalent of a tourist speaking broken english with a travel dictionary.

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:learning objective c

[Anonymous Coward]

The Apple Developer Connection / O'Reilly books "Learning Cocoa" and "Building Cocoa Applications" are pretty good starts, going from an introduction to Obj-C to writing complex GUIs.

Re:learning objective c

[BitGeek]

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.

Re:learning objective c

[Anonymous Coward]

Yeah just learn Objective C, I'm not that good of a coder and it wasn't hard for me to learn a good portion of the language with just highschool c++ class experience. Plus there is an incredible amoun t of docs and examples

Re:learning objective c

[roderik]

With minimal C and no ObjC experience I plunged into a project (fortunately with some experienced collegues) and was up and crawling in no time.
This was over seven years ago, I still use it every day as a WebObjects developer, and I am still very pleased.

Once you grasp the concepts, ObjC is a very nice language indeed. Especially categories are yummy :-)

just my 0.02

Roderik [ObjC retain]

Re:learning objective c

[RAMMS EIN]

There is a distinction here between learning the language per se, and learning to program in the language. Usually the efforts required are inversely related; assembly language is trivial to learn, but awfully hard to program in. One can, indeed, learn all of C's syntax by heart in two days, but the same isn't true for the C library or the Way to do Things (WOW) in C. However, if you are learning C just so you can learn Objective C and code for Cocoa, you don't need to learn those; you will be using the Cocoa libraries and Way to do Things (WOW). Therefore, a crash course in C syntax should be sufficient here.

Besides, the original poster seems to already know see fairly well, considering that he is looking for IPC with BSD layer processes. My advice for him is to stick with what Apple prefers (apparently Cocoa/ObjC) if the apps are meant for OS X only, and with a portable library (wxWindows?) otherwise.

---
M$'s software sucks? So what? So do vacuum cleaners, and still everybody uses them.

Re:learning objective c

[Anonymous Coward]

Actually with the latest dev tools (gcc 3 based) you no longer need to declare your locals at the beginning of a block, even in straight Objective-C.

Re:learning objective c

[Art Tatum]

Cocoa is portable and ported. See GNUstep

Seems like you answered the question yourself.

[tqbf]

If you need "clean and easy" integration with "BSD IPC" (the native programming interface of the underlying Darwin operating system), you need to be able to use its C-language calling interface. Of the 3 kits you mentioned, Cocoa/Objective-C is the only one that offers that.

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.

Re:Seems like you answered the question yourself.

[Anonymous Coward]

GCC includes an objective-c front end, and GNUSTep aims, as I undertand it, provides the request libraries for the GUI. If you write in Cocca, then it should be a fairly straight port to UNIX using GNUStep. At least in theory (practice is another manner).

Cocoa all the way

[petrilli]

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.

Re:Cocoa all the way

[petrilli]

Oh yeah, I forgot. Notifications, and Distributed Objects are trivial in Objective-C. They rule, they rock, they're fast to build IPC with. They have different goals, but they are very quick for specific targets, read about them, worship them, they are what Aqua uses all over hte place.

Re:Cocoa all the way

[BitGeek]

If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason

This is just a bit of bigotry.

Java is an excellent language and it is very well supported under cocoa and on the Mac.

There is a good reason: cross platform applications.

While I like Objective-C over Java, those are the only two languages I'd recommend anyone write in-- get rid of RealBasic, C and C++ before you get rid of Java.

Its common for people to take a macho attitude and pooh-pooh java, but this is just as silly as those who think real programmers write for the command line and pooh-pooh the gui.

Java's future is assured, while objective-c's not. I prefer objective-C but telling someone there is no reason to use java is just bad advice.

Re:Cocoa all the way

[Frymaster]

There is a good reason: cross platform applications.

there are also a bajillion (jillion^2) libraries and class out there in java that can be super handy. just browse freshmeat and you may find that half yr backend is there for you already... and lgpl'd.

real basic? heck, i'd choose applescript over that! you can build a pb/ib project in applescript very fast... and, once again, a jillion osaxen for you to plunder.... the drawback, of course, is speed in execution but if you need a prototype right now for that clueless vencap dude...

Re:Cocoa all the way

[Art Tatum]

There is a good reason: cross platform applications.

Objective C and Cocoa are cross-platform as well: GNUstep. Runs on UNIX platforms, alpha state under Windows, graphics backend can be easily ported to BeOS or anything else.

Re:Cocoa all the way

[BitGeek]

They sure are. Which is not to say that Java is worthless, I'm sure for many applications Java is the preferred xplat strategy.

And I look forward to the day when Apple or someone else makes Cocoa fully crossplatform.

Re:Cocoa all the way

[Art Tatum]

And I look forward to the day when Apple or someone else makes Cocoa fully crossplatform.

Heh, Apple is scared to death of people writing cross-platform software--they've been quite forceful in discouraging companies from even taking a look at GNUstep, for instance. The idea that people can market their software to users who can buy cheap x86 hardware is frightening to them.

Re:Cocoa all the way

[BitGeek]

Can you provide some example of Apple using force to keep people from using GNUstep.

Is suspect that is a false statement.

(Remember, force has a specific meaning.)

Re:Cocoa all the way

[Art Tatum]

Unfortunately, I wasn't the one involved, so I can't give you first-hand evidence. Someone in the GNUstep community did say that they queried several older OpenStep software developers (Omni, for example) about porting their software to GNUstep and supposedly got the answer that, while they would be willing in theory, Apple had already warned them that they would drop all support for them. Maybe that was false, exaggerated, or twisted, I don't know.

Now, one thing I *was* party to was the threatening email that Steve Jobs sent to Lucas Wagner in April of 2000 (there was some discussion on the GNUstep mailing list). He had started a company to offer some kind of commercial support for development of cross-platform apps with GNUstep, and got a threatening letter from Steve Jobs personally. RMS got involved and there was a lot of back-and-forth; I believe it was eventually concluded by FSF lawyers that Apple was just trying to intimidate the guy and didn't have a real case.

Lucas and William Adams did mention a case back in 1995 where someone built a WebObjects clone and was then intimidated and threatened by Steve Jobs (at NeXT, of course), leading him to give up the project.

Now, some of these events may be construed in various ways--and I can't prove that Apple wants to destroy cross-platform development; but considering their core business (hardware), it would certainly not be in their interest to give Mac users any kind of choice.

Non-commercial Cocoa developers are a different story, of course. However, some on the GNUstep mailing list who also belong to Cocoa development lists say that Cocoa developers have no interest in helping GNUstep. Supposedly, they just don't care about having cross-platform applications either. To me, it just seems cool that it can even be done, but I guess we don't march to the same beat....

Re:Cocoa all the way

[BitGeek]

Unfortunately, without knowing the details its hard to form an opinion. I googled but couldn't find anything linking lucas and jobs.

Back when people were releasing aqua themes there was a lot of flack about how apple was being asinine in its threats, but it turned out that the people were using apple graphics in their themes and were violating apple copyrights directly.

I find it hard to believe that someone built a webobjects clone and was intimidated out of releasing it-- anyone with the resources to produce such a project could afford a lawyer- webobjects is rather big.

But the code is also apples copyrighted code. I don't know how you can make a clone without violating the code, even if you just reproduce the apis-- the apis are copyrighted as well.

Openstep was an open standard, right? So that supports gnustep.

I think cocoa developers aren't helping much because they are working on applications and are focused on that. PErsonally, I could help in the future, if Gnustep looks like its going to be viable (Which is something I simply haven't researched yet because it isn't the appropriate time to consider porting my app.)

I think it would be a strategically good move for apple to move cocoa to windows, and I suspect any threats are probably due to apple having plans along those lines-- rather than apple not wanting such an entity to exist. But I could be wrong.

I do think apple recognizes that what they have is a platform, they are not just a hardware company, and they do want the platform to be strong, but hey want it to be done in such a way that the mac is the first class citizen.

Re:Cocoa all the way

[Art Tatum]

I googled but couldn't find anything linking lucas and jobs.

Here's where the thread starts (it's hard to follow, Geocrawler's threading sucks). The page where the thread starts is here. It does seem a little odd at first, but keep reading, it's all in there. The post about the WebObjects guy is here. Of course, you can make what you like of these posts, but when you read the entire discussion from beginning to end, it appears to be credible (the fact that Wagner was also around for quite some time before and after the incident, and made some contributions to the project, also lend some legitimacy to the whole affair).

But the code is also apples copyrighted code.

No proprietary code is used in GNUstep or its applications; so we're safe there.

I don't know how you can make a clone without violating the code, even if you just reproduce the apis-- the apis are copyrighted as well.

Well, the API spec is "open" (Sun and NeXT released it on October 19, 1994). The GNUstep project clean-roomed everything from that "open" spec. Thus the conclusion that the project is on solid ground.

I think cocoa developers aren't helping much because they are working on applications and are focused on that.

Well, one way they could help is to make sure that their applications are portable. This does take a little effort, however, and people have said that they don't want to even look at the project unless porting is effortless--and yet, they aren't willing to assist in *making* it effortless. I don't know how accurate that assessment is.

PErsonally, I could help in the future, if Gnustep looks like its going to be viable

Well, it's already in a fully useful state. Applications have been written with it, and they work well; for instance, GNUmail is nice, works extremely well, and runs on OS X as well as GNUstep platforms. There are quite a few other applications already (check out the GNUstep community site). We even have usable Interface Builder and Project Builder clones.

(Which is something I simply haven't researched yet because it isn't the appropriate time to consider porting my app.)

I understand. But the problem is, it can be a difficult job to port later if you don't take some considerations early on in the project. For instance, you can't use QuickTime because of a Sorensen patent--there's not much we can do about that one. But there are some newer clsses in Mac OS X that aren't implemented yet in GNUstep. We need people interested enough to implement, test, or fix them. That means OS X developers, mostly. And they're not interested, as noted before. :-)

I think it would be a strategically good move for apple to move cocoa to windows

NeXT produced Yellow-Box, which was just that. There was a lot of hope that Apple would continue to offer it when they bought NeXT. There were a lot of disappointed OpenStep developers when the decision was made to drop it. It's pretty well established that Apple's main source of revenue is hardware. There's been speculation that they might--*might*--consider porting the OS to x86 (most of the work was done back in the NeXT days) but simply offering people the possibility of using the development environment to write Windows applications is definitely not in their best interest.

Great to hear that you're interested in GNUstep, though. We need all the help we can get, even if it's just allowing the porting of applications. The Cocoa APIs and dev tools are very nice, and would make UNIX development much more fun and productive.

Re:Cocoa all the way

[BitGeek]

Thanks for providing the references. The lucas guy seems a bit anti-apple, or at least confusing. He doesn't give the context-- I mean, did he write steve looking for sanction to recreate cocoa? If so, I can totally see steve saying "Don't use our intellectual property".

That's not a threat. That's a request, and to follow it up with "nothing good can come from" is to back it up with concern. IF he had declared that Gnustep used Apple property that would be a different matter, but he didn't-- it seems clear to me that steve doesn't know, and his one line, terse email (which exactly fits the format of the one email I've gotten from him-- which was a response to one of my emails) is just warning people not to duplicate apple's stuff.

Its no suprise he's so terse given how this "incident" is later characterized by you and others. I'm not flaming you, I just think you're over reacting. Actually, I think most people over react to everything apple does-- the faithful declare their faith betrayed, the haters use to to "prove" apple is the ultimate evil. More often than not these positions are taken not on things apple has actually DONE but things its rumored to do, or in this case, even less.

Or, in shrot, its not clear that steve knows or thinks that gnustep was using apple IP, he was just warning them not to.

To be honest the biggest thing that holds me back about using Gnustep (Though my primary application can't work there, I have a shareware app that could) is concern about the GPL and the GPL infecting my code making it impossible to sell.

In theory there should be no risk of this, in practice there is.

But I haven't researched it and I'll look into it when the time is right.

Thanks for the discussion.

Re:Cocoa all the way

[Anonymous Coward]

"And thus, I leave slashdot."

Why can I still smell you, then?

Re:Cocoa all the way

[Anonymous Coward]

"And thus, I leave slashdot."

Talking out your ass again?

Re:Cocoa all the way

[Art Tatum]

Thanks for the discussion.

Sure. Feel free to drop in anytime. :-)

(Oh, PS: Just as an FYI thing for the future, GNUstep is LGPL'd.)

Best Framework for Mac OS X

[Anonymous Coward]

Do not use Carbon. The Carbon API has to go through a compatability layer, so any program written in Carbon will always be slower and less capable than its Cocoa version. Also, the Cocoa API is actually very easy to use once you learn the very simple connect protocols. Go to www.macdevcenter.com and goto the cocoa column for some great examples.

Re:Best Framework for Mac OS X

[akac]

Wrong. CLASSIC goes through a compat layer which is probably what you mean. Carbon and Cocoa are FULLY native on OS X. In fact, some Cocoa calls actually call Carbon API funcs. Even Apple developers use Carbon (iTunes) and mix Carbon and Cocoa in the same app.

Re:Best Framework for Mac OS X

[malice]

You clearly have no clue what you're talking about. Many parts of Cocoa are built on top of Carbon -- there is no "emulation layer" for Carbon calls, nor are carbon applications inherently slower than Cocoa applications.

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

[Twirlip of the Mists]

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.

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:Best Framework for Mac OS X

[Anonymous Coward]

Malice, i think you're the one mistaken. Mac OS X has several layers. At the bottom is the XNU Kernel (mach with some bsd file tools that would usually be in userspace but put here for speed), then there's the DarwinBSD layer (a mix of Free, Open, and Net BSD, with some NeXT stuff thrown in). On top of that is the Core Foundation. Carbon and Cocoa both are atop the core foundation. Carbon is the cleanup of the old Mac OS 1-9 Api. Its a mess. You only need it if you are a legacy Macintosh Programmer. If you know what MPW, Codewarrior, ResEdit and others are, you apply. If you have used a Mac before OSX, you apply. Cocoa is fantastic. It's objective c with some very powerful frameworks. Objective C is just standard C with some simple extensions. The frameworks might take you a while to learn, but thats because they are so extensive.

A cocoa app takes less code to write and you get it done a lot faster. If you are a programmer, you learn new languages all the time. It took me 2 hours to learn objective c, and I came from a strong c++/java background.

Its a cakewalk to take a commandline unix app and wrap a cocoa gui around it. The Gui made in interface builder takes up NO CODE.

You can also intermix c, c++, and objective C.

Cocoa is the best way for new programmers. If you doubt me, do the Currency Converter tutorial the Carbon way first, then do it the Cocoa way.

Re:Best Framework for Mac OS X

[Anonymous Coward]

Bollocks! Cocoa is a continuation of YellowBox (remember when OS X was Rhapsody, and there was an Intel x86 port called YellowBox for Windows NT?) and is *very* cross platform. Carbon is only cross platform between OS 9 and OS X. Cocoa can, and previously did, recompile on up to 9 architectures (x86, SPARC, HP-PA, PPC, MIPS). I'd imagine one day that'll come back considering Interface Builder still has an options combo called "Localization & Platforms".

Re:Best Framework for Mac OS X

[Morky]

I think iTunes is Carbon because until recently, they have been moving the OS 9 version along the same upgrade path. I don't think you'll see anything new in Carbon out of Apple unless it's an OS 9 port of an app from a recently purchased company.

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.

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.

Re:Best Framework for Mac OS X

[fault0]

> Many parts of Cocoa are built on top of Carbon

Well, sorta. Most parts of Cocoa and Carbon are built in top of CoreFoundation.

I would say, however, for someone who doesn't know either Carbon and Cocoa, Cocoa is quite a bit more applicable for use in the future. Carbon will die sooner or later, perhaps to the successor to OSX.

Let the application dictate the language

[ageitgey]

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.

Re:Let the application dictate the language

[bnenning]

Good advice in general, but regarding this point:

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.

Re:Let the application dictate the language

[Milo77]

Why couldn't you code a 3D game in java? The torque game engine that tribes was written in has a core of C++ code that is basically scripted into the "game" by a scripting language they rolled themselves(looks kinda like javascript). I don't know why they didn't just use JAVA through JNI - except that their gui component scripts are more elegant than java. Games have to be so "MOD"ular these days that a big piece of monolithic C code just isn't going to cut (assuming you want a mod community to develop). JAVA is a perfect plugin language. I would not be surprised at all if some future games are released with a class library for JAVA extensions. For one, it would give all those out of work JAVA programmers something to do :)

Personally, I think that JAVA is to the point where the whole game could be written in JAVA (of course calling OpenGL through JNI). I don't think it would be all that slow, and if it did why not just include gcc on the game CD and a process to compile the game engine into native code (optimized for the local system).

Why java? because I like designing programs not writing them, and C/C++ makes writing them painful.

Re:Let the application dictate the language

[davehaas]

If you are porting your java-based massive application to Mac, than ObjC is probably out.

You're taking programming tips from someone who uses an IF-THAN statement? ;)

Nothing wrong with Objective C

[zulux]

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

[Sahib!]

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

[zulux]

Funny, that's just what Apple did.


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

[Ageless]

Unless I am sorely mistaken, the kernel that runs OSX is not written in ObjC. While a OS is more than a kernel (as RMS will gladly point out) the bits that talk to the hardware are the important ones and they are not ObjC.

Re:Nothing wrong with Objective C

[jkujawa]

I've not downloaded the XNU sources to take a look, but I do know that OS X kernel extensions are generally written in C++, amazingly enough.

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.

Re:Nothing wrong with Objective C

[Sahib!]

Are you seriously claiming that the kernel of the OS is written in Objective C?

I didn't see myself claim that the kernel of Mac OS X (Mach) is written in Objective C. However, a kernel does not an Operating System make.

Re:Nothing wrong with Objective C

[BitGeek]

While a OS is more than a kernel (as RMS will gladly point out)

But an "Operating System" without a kernel is NOT an operating system, and that's why RMS doesn't get any respect anymore.

Why not Java / Swing?

[hoegg]

Forgive my inexperience with OSX programming, but some of the features you seem to be interested in are not OSX specific.

Easy IPC can be accomplished numerous ways using vanilla Java (RMI, conventional Thread communication), and you can go with CORBA for language-neutral IPC. And I think Java Threads are as good or better than BSD processes.

The UI decision is less important than the underlying program architecture and language/framework choice. Swing is the most obvious choice, but there are others.

Erase him

[Clock Nova]

I wish I hadn't posted to this topic so I could use my remaining mod points to mod this down. Could someone do it for me, please?

Depends where you start

[Anonymous Coward]

The answer to this is going to be different if you're (a) writing something from scratch or (b) porting a mass of existing codes.
Let me put my own spin on this question for the /. experts to answer. If you have a 200K-line C++ Windows app to port, would you

1. Carbonize it?
2. Leave it alone and add a Cocoa interface layer?
3. Rewrite the whole bloody lot in ObjectiveC?

Re:Depends where you start

[Anonymous Coward]

I'd pick...

3.) Rewrite the whole bloody lot in ... Java ....

Now I never have to port my application again.

recompile.org

Mozilla

[Fished]

I asked myself the same question a few months ago, and came to the conclusion that unless/until I have an application that requires a native API, I would do everything in Mozilla. In practice, this means a combination of XPCOM, XUL, RDF and javascript. It's like developing a really advanced web page, but you're not stuck in a browser framework.

Several advantages:

1. Easy cross platform. Your app will run on any platform Mozilla/Netscape run on.
2. Easy development. Subjectively, development goes a lot faster than under a traditional framework.
3. 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.02

Patrick

Re:Mozilla

[Lao-Tzu]

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 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

[Pahroza]

And when you put together that page that works only in mozilla and mozilla releases a patch that fixes some bugs and introduces others, are you going to tell your customers that they can't upgrade their browser because your application no longer works with it ?

Re:Mozilla

[Twirlip of the Mists]

Dude, you have got to be kidding, right?

Re:Mozilla

[Fished]

People responding seem to be missing a crucial point: I am not talking about a web application here. I am talking about using the mozilla framework to develop a local application. This is actually how Mozilla, including Mail, Messenger and Composer, is developed.

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.)

Re:Mozilla

[Jorrit]

He is not talking about Mozilla The Browser. He is talking about Mozilla the Application Framework. Mozilla is more than just a browser. It is an entire application framework in which you can make applications that do NOT require or run in a browser.

Greetings,

Re:Mozilla

[Pahroza]

I stand corrected.

Re:Mozilla

[Frymaster]

gtk+ apps do not run in the gimp. apply analogy where necessary.

Re:Mozilla

[Anonymous Coward]

Anybody who thinks that serialization is beautiful in MFC has never tried to create the second version of his product with new features.

If you want serialization and performance is not the issue than XML should be your serialization of choice. Don't stick yourself in the backwards compatibility trap of MFC Serialize and CArchive, even with versioning.

Re:Mozilla

[Anonymous Coward]

Mac users want native apps. XUL apps don't feel like proper native OS X apps. This explains why Chimera (Cocoa front end, Gecko back end) has become so popular so fast.

(More Chimera bugs are resolved as DUPLICATE than as FIXED, which clearly indicates that Chimera is popular. :-)

Re:Mozilla

[Lao-Tzu]

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.

Speaking from experience...

[Anonymous Coward]

I have been programming for Macs for the past 7 years..

First of all, Java. Java unfortunately is still too slow in its execution time. Yes there have been improvements, but they're not up to par yet.

Cocoa is alright, except that it uses Objective C. Objective C is a bastard child of C and C++, and it doesn't really mesh too well.

Which leaves Carbon. Nice, clean C++. Speedy execution too. Go for Carbon.

Now Nextstep, that's a whole different ballgame. ;)

Re:Speaking from experience...

[lemkebeth]

You wrote:

Cocoa is alright, except that it uses Objective C. Objective C is a bastard child of C and C++, and it doesn't really mesh too well.

C++?

Objective-C is an extensions to C (like C++) but, for the extensions draws on Smalltalk for inspiration.

In addition you wrote:

Now Nextstep, that's a whole different ballgame. ;)

Cocoa is an updated NeXT API.

Re:Speaking from experience...

[Twirlip of the Mists]

Cocoa is alright, except that it uses Objective C. Objective C is a bastard child of C and C++, and it doesn't really mesh too well.

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...

[LeninZhiv]

I believe the OP must've meant to say

I have been programming my 7-year-old Mac for years

rather than

I have been programming for Macs for the past 7 years.

Re:Speaking from experience...

[Anonymous Coward]

> Oft-troublesome C++ features

yet powerful if you take the time to learn them

Re:Speaking from experience...

[Twirlip of the Mists]

I don't usually comment on this sort of thing, but how could my post have been interpreted as flamebait? That's just confusing to me. Can anybody shed some light on this? Maybe I was offensive in a way that I'm just not seeing.

Re:Speaking from experience...

[Twirlip of the Mists]

Yes, they most definitely are. But for programmers with less experience-- say, the 5-year programmer instead of the 10-year programmer-- features like multiple inheritance or overloading can cause more problems that they solve. A complex class hierarchy with templated classes, lots of cross-inheritance, and overloading happening all over the place can be a real bitch to maintain.

Re:Speaking from experience...

[Anonymous Coward]

Don't confuse your personal unwillingness to change or adapt to new things as something affirming the "cleanness" of C++ (not exactly something which C++ is known for, I think we'd all agree).

It seems to me that to some degree this is the hurdle that Apple has to face -- getting people who are already comfortable to adapt to a new paradigm.

Re:Speaking from experience...

[BitGeek]

Yes, when you say something strongly (eg: not couched with lots of "I think" and "if its ok with you for me to think this way, my opinion would be.. but if its not ok, I retract what I said") and the moderator disagrees with you, and is your tpyical slashdot incompetant pseudo-geek idiot, they will mark you as flamebait simply because they disagree with what you said.

Moderation seems to often be more about whether the moderator agrees with you than in weeding out the actual flamers.

Re:Speaking from experience...

[fault0]

> Objective C is a bastard child of C and C++, and it doesn't really mesh too well.

What? Objective C is older than C++.

Re:Speaking from experience...

[Twirlip of the Mists]

See, now that's the BitGeek that I've come to know and love. ;-)

Re:Speaking from experience...

[egg troll]

Mastering C++ can take years, while mastering Objective C is a task for a couple of afternoons.

That makes you sound like a dismissive, arrogant ass. I don't know anyone who can master a language in a few afternoons.

Don't overlook REALbasic

[dpbsmith]

I'm not sure whether it is suitable, but It does give access to the full API via "declare" statements.

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

[Anonymous Coward]

I agree, REALbasic is Not In Any Way the mac equivilant of VB.

(Sure its expensive, and dies for no reason sometimes, but so does windows, and you don't hear your boss complaining...)

Seriously though, REALbasic just might be the way for you to go. Give it a try, and if you like it, you should buy it.

recompile.org

Re:Don't overlook REALbasic

[Pahroza]

How could someone possibly overlook RB? Have you seen the footprint of RB apps ? Blech. Cocoa is the way to go.

Re:Don't overlook REALbasic

[fdiv_bug]

I used REALbasic for a short time in Mac OS 9, and I found it to be a fantastic solution for application design. The language is simple and very easy to learn and the UI design tools work very well. It also lets you build apps for Mac OS 9, Mac OS X, and Windows all from one project; while I never tried this myself, I've never heard any complaints about it. REALsoftware also has a bunch of moderate- to high-traffic mailing lists for discussion of various aspects of REALbasic coding, and they're frequented very often by REALsoftware people, including the CEO Geoff Pearlman. You couldn't ask for better support for your money from them.

The only major drawback is that it costs money, but you can grab the demo and start toying with it to see how well it works. To echo the other posters, it's not for low-level or realtime performance.

Again, I agree with both posters here: You may be missing out on the right solution if you overlook it.

Re:Don't overlook REALbasic

[happystink]

Expensive? It's only 99 bucks I think, as long as you only want to compile fo Mac platforms, not too shabby for what you get, and the IDE is fantastic comparedto VB.

Re:Don't overlook REALbasic

[happystink]

I absolutely love RB for Mac apps, but the cross-compile stuff for windows is actually the source of many complaints. The marketing materials make it sound like you can write once for mac and then compile and run on Windows, but it isn't the case, you have to test on Windows very often while compiling or you'll run into big problems, especially without a windows debugger. This might change somewhat when REAL release the IDE for windows (!) sometime soon, as just announced (i forget the release date, i think early 2003).

Re:Don't overlook REALbasic

[BitGeek]

It seems to me that Interface Builder has supplanted the need for languages like RealBasic and Hypercard et al.

Interface builder and the appkit give you the quick and easy and powerful gui devleopment-- with more depth than realbasic, in the languages correct for professional development (Applescript, Obj-C, C, C++, Java).

Realbasic seems great for learning (and thus may be appropriate for the person who started this topic) but not for professional development.

If you need a quick app that can run on multiple platforms and are new to programming, then use RealBasic.

IF you need multi-platforms and are an experienced programmer, use Java.

IF you don't need multi-platform, use Objective-C.

Re:Don't overlook REALbasic

[lrivers]

If you don't know anything about REALbasic, then you shouldn't steer people away from it. Many of its most ardent fans are hardcode programmers who like being productive. Many people use REALbasic to make large, complex, powerful apps.

Re:Don't overlook REALbasic

[BitGeek]

Actually, I do.

No, hardcore programmers do not use Realbasic. Lower level programmers do. And that's fine. There are languages for every level... and as they progress, they can graduate to better tools.

Nobody uses real basic to make large, complex powerful apps-- at least in terms of how those terms are used to reference other applciations. Even iApps would be very difficult to do in RealBasic.

Nice as it is, if you're spending all your time dealing with the OS's API in C, then you might as well not be using Basic, right?

Its great for what it does, and I don't begrudge it. I certainly enjoyed using it when I did a couple years ago for a quicky application that didn't need to do much.

But if you want to be programming in the big leagues, you need to eventually migrate to Cocoa. (Take your time, its not like programming in basic is a waste of time.)

Re:Cocoa all the way - Mod Parent Up

[Anonymous Coward]

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

What about QT?

[wray]

I am not sure of your position, (because the developer license costs money for Mac OSX) but QT has the advantage of porting to about every platform there is.

Re:What about QT?

[JohnG]

Where in the blue hell did you hear that the developer license for Mac OS X costs money. The OS ships with developer tools.

Re:What about QT?

[Josh]

On the topic of QT, I'd like to pose the question, for those, who know, of what underlying API QT uses for the OS X specific part of the toolkit. Is it Carbon?

Re:What about QT?

[statusbar]

Yes.

--jeff++

Re:What about QT?

[SilverSun]

quoting trolltech:

Qt/Mac runs on Mac OS X. It uses the native Carbon API and does not require any special libraries.

Qt/Mac can be used with Apple's Project Builder and the gcc compiler that is shipped with Mac OS X.

It runns just fine. porting from Linux to Mac? No, just recompile.

Re:What about QT?

[gnuadam]

Not 100% sure (because I'm too lazy to look at the trolltech website) but I think he was refering to the fact that getting the QT developer licence is not free for mac os x, unlike in linux, where they give free license. This has nothing to do with the too often uninstalled extra CD apple ships with their operating system.

Re:What about QT?

[JohnG]

Oh, OK, I'm an idiot! Apologies to the original poster! :)

native != better

[Anonymous Coward]

Ouch! One big problem with "going native"
is that you tie your design and implementation
to the vendor's world view du jour. Don't
fall for this. Keep portability in mind;
you may have to implement it "native" to
actually get in running and take advantage
of some features. Keep it so that you can
port it any environment or support other components.

Re:native != better

[Twirlip of the Mists]

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.

Re:native != better

[BitGeek]

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.

QT can be the right solution

[statusbar]

If the app GUI is fairly simple, do the back end in a c++ library, and do the front end in Cocoa.

But if you have a complex GUI, do take a look at QT/Mac from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.

--jeff++

Re:QT can be the right solution

[dasmegabyte]

Wow. And it also destroys the great common interface Apple worked so hard for.

No thanks. I'll take a little headache to do something write rather than use a toy.

Re:QT can be the right solution

[Anonymous Coward]

Sorry to say this, but right now QT is f**king ABYSMAL on Mac OS X. Apart from completely disregarding everything about what makes the Apple GUI great - and giving us a set of horrible 'Aqua-like' widgets (if you get a 3 year old to look at Aqua and then get all the sizes and pixel placements wrong) - QT also only implements single-buffering of windows giving really bad redraw. It's horribly slow and also has yet to even try and build as a bundled Framework, meaning that you can't easily do drag-and-drop distribution of applications as you have to manually install into /usr/local/qt using Packagemanager. This is against the guidelines as it goes against easy version control and application file control. My company was pushing for me to use it and I gave up as it was so bloody awful. As it turns out, I managed to port our QT apps to Cocoa with minimum effort and ended up with an app no bigger than 800K rather than the 9MB atrocity everyone else had, whilst keeping the central non-gui C++ code untouched.

I say that all should keep away from Trolltech QT whilst these problems continue (write once yes, get the lowest common denominator on all platforms) until they either do a GUi abstraction layer to native widgets on platforms or give a better experience than Cocoa development. For chrissakes, they even wrote it in Carbon, but wrong, so that compiles broke on 10.2....

Re:QT can be the right solution

[lemkebeth]

For a moment there I thought you meant QT insead of Qt

We need to do something about the abbreviation confusion.

Re:QT can be the right solution

[printman]

So can FLTK, which also supports MacOS X and is a lot smaller.

Mind you, the look-n-feel isn't identical like Qt's (as a free software project, we can't buy Aqua like Trolltech did), but the "plastic" scheme is similar enough.

Re:QT can be the right solution

[statusbar]

Thanks for the info, that is very useful to know.

--jeff++

Re:QT can be the right solution

[Anonymous Coward]

The 3.0 version has some rough edges but have you seen the 3.1 beta2?

The 3.1 version uses a new Mac style that is implemented using the Appearance manager so instead of Qt emulating the Aqua look in 3.1 Qt gets Mac OS X to draw widgets natively. It looks native, hell it is native and you can even use themes like drawing board with Qt apps.

I'm not sure what you mean by Qt only implements single buffering, double buffering is built into Mac OS X itself. In most situations it's not actually desirable for Mac OS X applications to double buffer as that's a wasted duplication of effort since the display system does it for you.

Regarding Frameworks that's supported in 3.1 beta2, but you never had to install into /usr/local/qt you could just create a static build of Qt instead, that way you can drag and drop your application bundle as per normal.

It's true Qt 3.0 doesn't work on 10.2 but 3.1 beta2 does, and 3.1 is due out in a couple of weeks.

> I say that all should keep away from Trolltech
> QT whilst these problems continue

I think all the problems you have mentioned are actually fixed in 3.1 beta 2.

Disclaimer: I'm a Trolltech employee (yeah could you guess?).

Cocoa / Obj-C

[Sahib!]

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?

Re:Cocoa / Obj-C

[Sahib!]

Also, O'Reilly's Building Cocoa Applications 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:

• http://www.stepwise.com/
• http://macdevcenter.com/
• http://www.cocoadevcentral.com/

Re:Cocoa / Obj-C

[BitGeek]

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

[d3xt3r]

As another person just getting into the OS X programming game, I was wondering the same thing. After looking around Apple's web site, and playing around with the different frameworks, it became apparent to me the Cocoa + Obj-C was the way to go.

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:

1. Java Swing on OS X: I have a database tool that I am creating as a cross platform app that is written entirely in Java using Swing. It runs beautifully on OS X and looks (almost out-of-the-box) like a native application. However, it is still slower than a native app. Users who expect a snappy GUI will be disappointed with a Java Swing app on OS X. While it performs admirably better on OS X than Windows or Linux, I'd stay away from Java Swing if cross-platform binary compatability is not a major requirement.
2. Carbon: From what I could understand from Apple's web site, Carbon exits for one reason: to give developers a migration path from OS 9 to OS X. Carbon is a gateway API since Cocoa simply is unsupported on OS 9. It is obvious that Apple's go-forward plans are for Cocoa and Objective-C.
3. Java and Interface Builder: I serisouly recommend not using this combination. You are going to force your Mac OS X only application to run in a Java VM without the cross-platform benefits of Java. This approach only seems logical if your backend is written Java and you want to create native GUIs on all platforms. I would stay away from this for an OS X only application.

Re:use Cocoa

[ml10422]

> "Carbon exits for one reason: to give
> developers a migration path from OS 9 to OS X."

That's what Apple was hoping would happen. But a whole lot of 500-pound gorilla Mac applications have been ported to Carbon. As far as the companies that develop those applications are concerned the port to OS X is done. No way are they going to spend additional time and money porting to Cocoa.

Carbon is going to be around as long as OS X.

How about Qt/Mac

[SilverSun]

Qt/Mac from trolltech:

Qt/Mac runs on Mac OS X. It uses the native Carbon API and does not require any special libraries.

Qt/Mac can be used with Apple's Project Builder and the gcc compiler that is shipped with Mac OS X.

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

Re:How about Qt/Mac

[SilverSun]

To be precise Qt/X11 is GPL. There is a Qt/Win non-commercial version, but I guess you have to pay for Qt/Mac.

Re:How about Qt/Mac

[markalanj]

I have been using Qt for 2 years now on Linux & Windows. I really don't understand why everyone has to complain about moc sure it may not be a standard outside of Qt but damn it works!

The Trolls Rock!

Re:How about Qt/Mac

[Anonymous Coward]

moc is good. And since this is somewhat relevant moc actually fixes c++, extending it to support perhaps the most desirable features of java and objective c.

With moc you get the power of Java reflections in C++, that is you can at runtime inspect a QObject derived class determining which methods/properties it supports.

Objective-C is dynamic in the same way, it allows introspection of classes at runtime, making it possible at runtime to determine which methods/properties a class has, (and call those methods or add new ones).

Having praised this feature, I should remark that it is a powerful feature that comes at a price, reliance on dynamic runtime introspection means bugs show up as dynamic runtime errors rather than being quickly flagged as compile time errors.

Java Cocoa

[BlueGecko]

the Cocoa Java API [gets compiled to PPC binaries, lots of APIs available [think Google], but absolutely no decent documentation to be found]

First, Java Cocoa is not native. Your application will still run on the Java VM. In my mind, it fills a very narrow purpose: it allows you to quickly turn a 100% Java application into an application that behaves exactly like a truly native OS X application and which can take advantage of the niceties that provides (for example, Services support, Sheets, Quartz, etc.). Secondly, I hear the complaint about the lack of Java API documentation all of the time, and I honestly don't understand it. Admitting that I've been working in NEXTSTEP and later OpenStep and then Cocoa for a very long time, Apple provides a detailed Java API reference that has class-for-class and method-for-method documentation exactly on par with the ObjC documentation and also provides a tutorial for Java developers that literally produces exactly the same application as the ObjC Cocoa tutorial. You need merely do both tutorials to see how exactly the two APIs line up. The only somewhat legitimate complaint is that Apple examples typically come as ObjC, but how hard is it, honestly, to figure out that [aSpellingChecker ignoreWord: @"bodacious" inSpellDocumentWithTag: myTag] becomes aSpellingChecker.ignoreWord("bodacious", myTag)? The rules for ObjC-to-Java conversion of APIs and code are very straight-forward:

1. Any code relating to autorelease pools may be deleted and ignored (at least in basic code; by the time you need to make use of manual garbage collection in Java Cocoa (multithreaded code in the GUI being a big one), bluntly, you'll already know enough that it won't bother you)
2. Java class names remain identical to their ObjC counterparts, and are in either com.apple.cocoa.foundation if they are part of the ObjC FoundationKit and part of com.apple.cocoa.application if they are part of the ObjC AppKit. (QuickTime is in its own API and really is a separate discussion, since "QuickTime for Java" has existed for several years now and is more a part of Carbon than Cocoa.)
3. Method names for Java always consist of the first part of the ObjC identifier and always take the same parameters (except that NSStrings become java.lang.String). For example, (void)NSSpellChecker>>ignoreWord:(NSString *)inSpellDocumentWithTag:(int) becomes void NSSpellChecker.ignoreWord(String, int).

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]

[Have Blue]

If you are developing a GUI application from scratch and portability is not a concern, learn Cocoa. Interface Builder is hands down the best GUI-building tool in the industry.

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!

[critic666]

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

Re:Don't discount Cocoa!

[jericho4.0]

The tutorial linked to in this parent looks like it'll turn learning Obj-C from a 2 hour exercise to a 1 hour exercise. Thanks critic666.

Re:Java -- no question about it.

[Twirlip of the Mists]

Yeah, after all, there's no reason to write good software when you can just write portable software.

Least-common-denominator approaches are good for nothing-- except grade-school arithmetic exercises.

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).

Documentation

[matsukio]

I agree with most of those who have said that Objective C is easy enough to pick up in an afternoon. And in my experience, Objective C is preferable to Java for Cocoa development. And in my experence Cocoa is preferable to Carbon, not only because the Carbon featureset is a subset of the Cocoa featureset, not only because Cocoa is the native framework for OS X, but also because you can leverage the excellent development tools provided by Apple (especially Project Builder and Interface Builder). A dedicated programmer can learn how to use PB and IB and Objective C in a day or two, and proficiency in those tools will speed up your actual coding work more than enough to merit the time spent learning them.

Documentation for the development environment, as well as Carbon and Cocoa API tutorials and reference, can be found on Apple's Developer site.

Use Cocoa

[Anonymous Coward]

Let's get this straight: you want to learn an entire framework, and your primary complaint is about learning a minor extension to C?.

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.

WRONG - Carbon provides this too!

[linefeed0]

If you use Project Builder to build Mach-O Carbon apps (rather than CodeWarrior and CFM), you can use all the C-based Unix API's. This myth that only Cocoa's api's work on top of the BSD layer is so incredibly false.

Also, remember that CoreFoundation gives you some of Cocoa's advantages (reference counted data structures, for example) in Carbon. Not knocking Cocoa, but having Carbon as well gives you a lot of choices.

Re:WRONG - Carbon provides this too!

[Tokerat]

Exactly, if you are already familliar with Carbon-stype API (read: MacOS 9), it is a good way to go and will get anything done which Cocoa would do, although certian issues won't have quite as suave a solution as Cocoa would provide.

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.

Re:WRONG - Carbon provides this too!

[Art Tatum]

Exactly, if you are already familliar with Carbon-stype API (read: MacOS 9), it is a good way to go and will get anything done which Cocoa would do, although certian issues won't have quite as suave a solution as Cocoa would provide.

And your code also won't be portable to GNUstep.

Re:I recommend . . .

[lemkebeth]

You wrote:

Truth hurts, doesn't it, fanboys? If it isn't true, explain to me why what are free utilities for Windows machines are $20-$30 extortionware for the Mac.

: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).

The Master Of C

[Anonymous Coward]

Once you've mastered C-- which takes about two days

Oh yeah it's a piece of cake. What a lamer !
Just another one of those fresh new wannabe programmers. If you think you can master C in a couple of days, you probably didn't understand much about computer science to start with.

Re:The Master Of C

[oh2]

I agree. Mastering C takes at least three days, four if you need to go to the bathroom.

Re:The Master Of C

[Anonymous Coward]

If you are such a master of C, how come you can't program worth shit ?
Back your boldness with software.

Re:The Master Of C

[Twirlip of the Mists]

Uhhh... dude, are we talking about the same thing? The C programming language is incredibly simple. Hell, it only has 32 reserved words! (Plus or minus a few depending on your compiler of choice.) Any reasonably intelligent person who already understands programming concepts like functions and variables should be able to learn the entire C language in a day, maybe two.

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

[Anonymous Coward]

Uh, dude, learning the syntax and basic semantics of C in a couple of days? Fine.

Mastering C? That's a whole different story...

Re:The Master Of C

[Jorrit]

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,

Re:The Master Of C

[Anonymous Coward]

C isn't that bad - if you come from a STRONG OOP background. Those OOP habits WILL save you - the last time I wrote in C, I felt the OO influence just from writing XXXCreate and XXXFree functions - ctors and destructors that keep code mostly clean. And the void* isn't all that different from the casting of Object pointers you have to do with Java-style collections anyway.

That being said, there are two parts of C that are horrible and nasty: pointer arithmetic, and strings. As long as you NEVER try these and stay with well-established libraries, C is pretty easy. Try to wade in (and get the 2x performace boost for custom code) and you'll spend the next month working bugs out.

Re:The Master Of C

[ksplatter]

I think memory management is something that to master takes alot longer than 2 days ... and without POSIX API's C isn't anywhere near as useful. So yeah maybe you can learn syntax but to use C properly you need more than 2 days.

Re:The Master Of C

[orthogonal]

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.

Re:The Master Of C

[Anonymous Coward]

You're confusing mastering a language with mastering programming.

There's not a hell of a lot to master in C. Most of the 'mastery' I would venture you're talking about is related to the systems your code runs on.

Re:The Master Of C

[Anonymous Coward]

... and of course, if you were using Obj-C and Cocoa, you wouldn't have to worry about this...

You'd just use an NSMutableArray with its various object insertion, deletion and replacement methods and then use an NSEnumerator to move through the lists. You can even use 'performSelector' calls to emulate a foreach as in Perl or other scripting languages.

Re:The Master Of C

[Anonymous Coward]

Pointers are such a simple concept, why do people have trouble with them?

Imagine bytes in memory are simply numbered pigeon holes. The first hole is '0', and you go up from there.

A pointer is a variable that holds the address of another pigeon hole. Pretty fucking simple. And from there, it's only a simple step to pointer arithmetic. If a piece of data takes up two pigeon holes, incrementing a pointer of that type will increase the address value by 2.

The problem really is that not enough people learn about computers. They learn 'programming' as if it was at a higher level than it really is, and this is both bad and stupid. Teach the low level first - you need to UNDERSTAND the computer before you can instruct it.

Re:The Master Of C

[Frymaster]

yes, the basic *concept* of pointers is easy and the implimentation as outlined in the hello world calibre demo code that comes with most tutorials is simple... but the reality of memory management in non-trivial apps is quite different. why do you think there are so many memory profilers and leak-detectors on the market?

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.

Re:The Master Of C

[Anonymous Coward]

when you make an object a "reserve" is put on it.

Sounds like java, with it's reference counting... I sure hope it works better than java. In java, if I create a new object and add it to an array, then create another object of the same type, and add THAT to the array, I find that both objects in my array are the SAME REFERENCE.

Example: I have a 'ball' object with a colour property. I create a new ball with the colour red, and add it to my array. Then I create another new ball (using the keyword new) with the colour blue. Then I check my array, and both balls are blue. It seems as if java decided the reference to the original red ball was unused, and re-used it to create the blue ball.

Re:The Master Of C

[Anonymous Coward]

yes, the basic *concept* of pointers is easy

I was replying to a post that claimed understanding pointers is challenging. It's not.

Understanding pointers and writing a memory management system are two entirely different things, regardless of how much the latter relies on the former.

All it would take to make pointers practically transparent for the newbie is to educate them a little on how the damn computer works. I've met programmers who didn't understand memory. "What, you mean variables?". Sue me for thinking a programmer should have some understanding of his machine! ;P

Re:The Master Of C

[hazel_fiver]

Java doesn't work that way. Every "new" invocation would create a new Ball object:
e.g. new Ball("Red"); new Ball("Blue"); would always create two Ball objects.

Perhaps the member variable you used for the colour was a static/class variable?

For instance:

class Ball {
static String colour;

Ball(String c)
{
colour = c;
}
.
.
.
}

would cause the behaviour you described.

Re:The Master Of C

[jeremyp]

Why do people have trouble with pointers in C? Well let's see:

What about the subtleties of:

FILE* p ;
char* q = p ;

p++ ;
q++ ;

or the difference between the following:

char* argv [10] ;
char argv [10][10] ;
char (*argv) [10] ;

and the following, why does the assignment in foo work albeit get thrown away when the function exits, but the assignment in main not even compile:

void foo (char a [], char b [])
{
a = b ;
}
char x [10] ;
char y [10] ;

int main ()
{
x = y ;
}

The basic concept of pointers is quite simple, but to code in C effectively using them requires days of practical experience.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Might want to read this

[Mindcrym]

Check out the article Introduction To and Experiences With Mac Cocoa from Kuro5hin.

Only on X11

[yerricde]

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.

Re:Only on X11

[markalanj]

Not if you purchase a license! Qt is well worth the money!

Why not wxWindows?

[kollivier]

wxWindows is a cross-platform GUI toolkit which emulates the native look n feel of the platform it is running on. It's written in C/C++ and runs on Windows, Mac, and Linux. The url is http://www.wxwindows.org. It gives you the cross-platform benefits of Java, as well as access to the underlying BSD layer.

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?

[Anonymous Coward]

It's doesn't emulate at all. It actually calls the carbon api, they're just adding a portability layer on top that makes sense for all platforms.

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.

Fink?

[yerricde]

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 (i.e. d*b**n gnu/mac os x) are you talking about?

Re:Fink?

[Anonymous Coward]

Stuff that requires running an X server doesn't count :).

~~~

Re:Fink?

[jericho4.0]

Gee, and then there's the little matter of;

UI Builder, Project Builder, OpenGL Vertex Shader, IPhoto, ITunes, IMovie, the list goes on.

Show me where I can buy a realtime Vertex Shader IDE for any amount of money.

Re:Fink?

[yerricde]

UI Builder, Project Builder, OpenGL Vertex Shader, IPhoto, ITunes, IMovie, the list goes on.

What are those? Aren't they either included with the Mac OS X distribution or available as a free download to all licensees of Mac OS X?

Re:Fink?

[iMacGuy]

Right, that was his point.

Use Jython or JRuby with SWT

[fxj]

write your basic classes in java and
use jython to set up the application.

Have you had a look at SWT ? Eclipse is written in it and it is really fast !

AppleScript?

[CowboyNick]

Why not just use AppleScript? :)

Here's how I see it

[Dr. Awktagon]

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:Here's how I see it

[Art Tatum]

As the self-appointed GNUstep evangelist, I'd like to let you know that you can develop your Cocoa/Objective C applications with Linux (or *BSD, or HP-UX, or Solaris, or...) using GNUstep's Interface Builder and Project Builder clones (Gorm.app and ProjectCenter.app, respectively) and have cross-platform OpenStep goodness.

The more that we can get new Cocoa developers to become aware of the project, the more nifty cross-platform applications we'll have. Oh, and there's a Windows graphical backend in an alpha state too. So, your Cocoa work should be easily portable to Windows soon too.

By default, I recommend Cocoa / Objective-C

[Anonymous Coward]

Mac users care a great deal about nativity and the app behaving like a good Mac OS X app. (Otherwise we could be using something cheaper and less elegant, right?) Cocoa is the most native thing on OS X. If you use Cocoa, you have an immediate advantage over competitors who use Swing or Carbon.

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?

[the_2nd_coming]

you can still compile C code with an objective-c compiler, infact, Objective-C isw a true supper set of OO features appened to C, so would you then not be able to use Coaca with C code as long as you compile into an objective c binary?

Re:Java -- no question about it.

[Anonymous Coward]

Who's to say that you can't write good software in Java?

Good software design is NOT about the language you use, its about how you use it. (something I'm sure you've heard before)

Saying that all Java code is poor is like saying that all books written in russian are poor.

this post just makes me angry

Along the lines of the myriad calls to use Qt...

[gnuadam]

...I'd also suggest taking a look at wxWindows. 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!)

Offtopic rant! :)

[brad-x]

Forgive me but I must say it! I hate the word "coding".

I think it's an unsophisticated word.

It's like using the word "boink" to describe sex, it doesn't work if you're having a serious discussion.

Re:Offtopic rant! :)

[Anonymous Coward]

Coding is the word for us oldskoolers.
I agree a fag that is planning to use Java should not use it, nor should you, which have no idea of what it means.

dudes in hell

[Anonymous Coward]

Uhhh... dude
Hell

Dude yourself !
Plus, do people in here have to say "Hell" all the time ? Just speak normally, be yourself.

You seem to be so above things. It's easy to have an attitude, it's another matter to actually know how to code.
Knowing the rules of Chess doesn't make you a champion, or even a player worth its name.

A, B, C, or NONE OF THE ABOVE. Not 'D'.

[tqbf]

He didn't give Carbon as an option.

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'.

[linefeed0]

Well, actually, among other things, it's faster. In particular, Carbon apps start noticeably faster than Cocoa apps, period. It's also more usable for porting of C/C++ based apps from other platforms.

NeXT had some cool ideas, but (starting with Mach, the first abomination of that category) some really shoddy implementation.

Re:A, B, C, or NONE OF THE ABOVE. Not 'D'.

[tqbf]

Why is Carbon better for porting C/C++ applications from other platforms over? C/C++ works just as well under Cocoa alongside Objective C as it does in Carbon. Moreover, coming from another platform, you're still going to wind up porting your UI code to a new toolkit. What makes you think the low level toolkit is easier to port to than the high level one?

Mach isn't a NeXT idea; it's a CMU idea. NeXT and Darwin aren't the only Mach operating systems.

Re:A, B, C, or NONE OF THE ABOVE. Not 'D'.

[BitGeek]

In particular, Carbon apps start noticeably faster than Cocoa apps, period.

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:A, B, C, or NONE OF THE ABOVE. Not 'D'.

[Anonymous Coward]

FWIW at least someone (myself) realises you're the only person who actually knows what they are talking about. Basically you are echoing the comments of the uninsanity guys, and they definitely know what they are talking about.

Pity none of the moderators have a clue.

suck it up, learn Obj-C

[relay_mod]

First of all, there's a "fourth" alternative that you did not mention: Carbon. It's a C API that represents a subset of the old Mac OS 9 APIs. It will give you access to Cocoa and CoreGraphics goodies while also giving you access to all of the wonderful Mach and BSD APIs.

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.

Re:Java -- no question about it.

[Twirlip of the Mists]

Who's to say that you can't write good software in Java?

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.

Objective-C++

[Anonymous Coward]

In order to fully utilize all the features of the Mac UI, you MUST use Cocoa with Objective-C.

Both Java/Swing and C/Carbon are subsets of what's available with ObjC/Cocoa.

I recommend you write the core functionality of your app in good 'ole crossplatform C++ and integrate it with a Cocoa/ObjC UI. Google for "Objective-C++" for documentation on how to bridge the two runtime environs.

You *could* write your entire app in Objetive-C, if you really dig late-binding and aren't a big fan of crossplatform compatibility.

Mozilla != MacOS

[tqbf]

You could develop for Mozilla (and, with some effort, wind up with something that would work in the COM/ATL/XYZ equivalent environment that Windows provides). You might even be productive in that environment. But you're not developing and OS X application, and you shouldn't kid yourself.

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).

Mac Os X Programming

[sickboy_macosX]

I like Cocoa, and the best Kit I have foudn that will let me Develop Cocoa and still write Classic Mac Apps is Code Warrior it handles it all very nice. Also if you wanna learn how to program or anything sign up over at Apple Developer Connection http://developer.apple.com/ It is free to sign up for it, and if you are a student you can sign up for The Student Subscription for 99 bucks. but thats how I would do it.

Re:Mac Os X Programming

[Art Tatum]

Letting all the new Cocoa developers know about GNUstep. It's a GPL'd implementation of Cocoa, and runs on all UNIX platforms (Linux, BSD, etc.) and Windows (the Application Kit graphics backend is in an alpha state). We have several applications written (including Interface Builder and Project Builder clones), some of which are completely portable to Mac OS X (like, GNUmail.app). It's fun and cool.

sure?

[jon_c]

If Moz is half as powerfull as IE it shouldn't be a problem, I've done some pretty amazing client side app development with IE and so has MS - actually i did it for MS, but thats another story.

The only issue i can see is if one wants to get out of the sandbox that is the browser, in those cases we used ActiveX objects, i dont know how possible something like that would be in Moz, at least with any portablity.

-Jon

JDK 1.4

[TheLastUser]

The IO was completely redone for 1.4. Maybe that cures your concerns. Now includes non-blocking io, which may be related to your threading issues.

You may be right about portability wrt some situations involving threads and sockets. I haven't run into this myself and would be interested in some examples.

All in all, I think one's chances of getting a portable app using Java are better than with any other language.

Re:JDK 1.4

[Tim Ward]

OK, in 1.4 you can, at least, get a list of the interfaces and IP addresses on the machine, but to get the subnet mask and default gateway for each interface you have to revert to something platform specific. ICMP? Forget it. Unicasting to a known MAC address when the destination device doesn't have an IP address yet? Forget it. Other low level protocols for which raw socket access might be useful? Forget it.

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.]

Re:Use Objective C + OmniNetworking

[FozzTexx]

There's a better sockets wrapper at http://fozztexx.com/FZBase/. It's multi-threaded which allows your program to receive data while it's interacting with the GUI, and also doesn't require you to mutilate your stock system just to compile it.

Try Qt

[Anonymous Coward]

Not only is Qt portable across 3 major platforms (MacOS, Linux/Unix, Windows), but its api really rocks.

Re:Try Qt

[Anonymous Coward]

It would rock better if it didn't suck so bad on OS X... trust me, our company has it and it really really blows big time.

Cocoa

[Anonymous Coward]

Cocoa is the framework of choice for most OSX programming. The mechanics and syntax of Objective-C is easy to learn--you can pick it up in a couple days. (Making full use of what it provides you is a different matter--it can take months to stop thinking like a C++ programmer and take full advantage of the dynamicism of the language.) If you're doing any GUI programming this is the framework you should use.

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...

[greygent]

If you had done the least bit of research before asking this question, you'd already know to pick Cocoa.

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.

If you were Really HardCore

[jazman_777]

Assembly. Show us what you've got.

Re:If you were Really HardCore

[BitGeek]

Premature optimization is the root of all evil.

Real artists ship.

People prefer software that actually works.

I'd rather be rich and not have the the respect of a poser such as yourself.

However, if you're working on a product to compete with mine, I can't help but agree that you should be using assembly for everything-- and to recommend that you create your own ui widgets while you're at it.

Re:If you were Really HardCore

[jazman_777]

However, if you're working on a product to compete with mine, I can't help but agree that you should be using assembly for everything-- and to recommend that you create your own ui widgets while you're at it.

C'mon, I was just joking. I could have said "Xlib", but I didn't want anyone to suffer a stroke.

What kind of IPC?

[Anonymous Coward]

If I read him correctly, he wants to be able to pipes, semaphores, or shmsegs, not any of the Java-specific IPCs. However, if he's amenable to other options, I've got to throw Cocoa's Portable Distributed Objects (PDO) out there; it is, bar none, the easiest IPC framework ever developed. Writing an IPC-enabled or network-enabled Cocoa application is quite literally only a few lines different than a standalone app.

Re:What kind of IPC?

[hoegg]

That would depend on the specific applications he wants to communicate with. IPC is only useful if you have some reason to be communicating with these other processes.

I have found that it can be much more productive to engineer the communication with each specific application than to build in generic IPC as a requirement a priori.

I suppose the answer to this Ask Slashdot should be a question: "What are the requirements for your application?"

You're sorely mistaken

[greygent]

Yes, they are, fucking look at the kernel source before you post drivel like this. Various parts of the kernel are coded in C, C++, and Objective-C++

Re:You're sorely mistaken

[Ageless]

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

Re:You're sorely mistaken

[xil]

Where is there any Objective-C++ in the kernel? I really don't think there is any in there, but you're welcome to prove me wrong. File names, please... I don't see any .m or .mm files in the xnu project in Darwin at all.

It's interesting to note that under Nextstep/Openstep, drivers WERE written in Objective-C (using the "DriverKit"). Apple decided to switch to C++ for OS X, to lower the barrier to driver authors a little bit.

Re:You're sorely mistaken

[Anonymous Coward]

The Objective-C runtime doesn't exist in the kernel context, therefore no Objective-C++ in the kernel.

Cocoa for sure

[Anonymous Coward]

Don't bother with these people that have used one and not the other. The fact of the matter is that oyu can actually do alot more in Cocoa, and its alot faster than Java apps, plus it also has many interfaces adn methods that carbon still doesn't have yet. Cocoa has free support for all of the Mac OS X services that are offred by other apps.

As for the learning curve, its no more than hour at most, its like C/C++ cept with different syntax when working with classes and objects.

There are many more reasons, a stroll through the Apple develope pages will shouw you what I mean.

pssst..... Python!

[ABetterRoss]

http://sourceforge.net/mailarchive/forum.php?threa d_id=1173890&forum_id=4355

You can now build pure Cocoa apps in Python...

many choices, choose one which fits your style

[tim1724]

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.

1. Choose a GUI toolkit
   • Carbon - a cleaned-up version of the original Macintosh Toolbox. It's big and complicated (as should be expected for something which has been evolving over 18 years) and may be somewhat annoying if you don't have previous Mac Toolbox experience.
   • Cocoa - the OpenStep API with a few new features. Clean and simple object-oriented interface designed around the Objective C language. Good for rapid development of GUIs.
   • Swing - Apple provides a Mac OS X implementation of Swing. With a little work, you can make a Swing program look almost native. (But not quite.. a few things end up looking or behaving slightly wrong.) A good choice if you want cross-platform Java code.
   • QT - The Mac OS X version is based on Carbon, so it should look like any native program. A good choice for cross-platform portability.
   • Tk - as in Tcl/Tk .. there's a Carbon port of Tk, but I've had some problems with it.
   • other cross-platform toolkits - There are a few others (wxWindows, for exmaple) but I don't know much about them. As far as I know, they're all built on top of Carbon.
   • Mac-specific libraries built on top of Carbon - things like PowerPlant (a C++ library from Metrowerks) make dealing with Carbon a bit easier.
2. Choose a language

   Most of the toolkits support multiple languages.

   • Carbon: It's intended to be used from C (although you'll still find a few remnants of its Pascal roots) so it's not object oriented. You can use it from C, C++ (directly or via object-oriented layers like PowerPlant), RealBASIC, and probably a few others.
   • Cocoa: It was designed around the Objective C language, but Apple also provides Java bindings. Java isn't a particularly good fit for Cocoa (better than C++ would be, though) so I don't recommend it. There is a Perl binding called CamelBones which works rather well (Perl and Cocoa go together very well in my opinion). I think Python and Ruby bindings may be available as well.

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.

Re:many choices, choose one which fits your style

[Anonymous Coward]

QT - The Mac OS X version is based on Carbon, so it should look like any native program. A good choice for cross-platform portability.

It should look like any native program, but right now it doesn't. In fact it's approximation of the OS X gui is so bad it looks like it's been drawn by a 5 year old. Why they can't use native widgets on each platform via an abstraction layer is beyond me, or do they want it to look like sh*t on all platforms?

Re: i suggest

[Anonymous Coward]

an OS with a spell checker, idiot! then again, this way we can tell you are an idiot without having to waste too much brain time.

No, you idiot.

[Anonymous Coward]

C is one of the simplest languages to learn. It is much simpler than Perl or Python, for example, because the latters' language definitions suggest abstract ideas that may be conceptually more difficult than the C's universal assembler paradigm. The difficulty with C is writing software in it, because it it forces everyone who uses it to keep books the irrelevant details that would otherwise be taken care of by a compiler for a high level language. For one example, if you were writing code for a desktop caluculator in C, that code would be littered with malloc()s, and not one of those mallocs will have anything to do with adding numbers.

So, C is easy conceptually, but hard to use because it is brain dead. People who like C either like to tinker or believe they're going to live forever.

Re:No, you idiot.

[Anonymous Coward]

How can C be simple to learn if, after you've learned it, you cannot write software in it? Seems to me you haven't learned it until you can write software in it.

Re:No, you idiot.

[Anonymous Coward]

"Hello World" is software, you egotist.

If being able to write good software is the mark of an accomplished programmer, then the world has incredibly few accomplished programmers.

Re:No, you idiot.

[Hilary Rosen]

"People who like C either like to tinker or believe they're going to live forever." Could it possibly be due to the stability and bug free compiler, compared to C++?

Don't forget GNUstep

[aleahy]

Cocoa is also relatively portable via GNUstep--an open source implementation of the Openstep API from which Cocoa was derived. GNUstep is a little bit rough around the edges, but apparently very usable at this point. See google for various links.

wxWindows

[Anonymous Coward]

There is already a port of wxWindows to the Mac, and quite sure to OSX soon enough.

Re:wxWindows

[Anonymous Coward]

here is the source forge project repository.

Re:How about Qt/Mac + Designer

[zorander]

Also, don't forget Qt Designer. It's one of the most capable interface designers I've ever had the pleasure to use.

For those who don't know, It outputs a .ui file (XML) containing a description of the class you've created. You edit code within designer (A major improvement) and then the user interface compiler (uic) and Meta-Object Compiler (moc) get their punches in and create source code/headers from the interface. Then your code can just use it like any other class.

Better yet, qmake handles all the dirty makefile generation from a project file format that one can learn in about four minutes (and that designer generates).

I wrote a fulle graphical and very functional remote services debugger in about eight hours total using designer (I had used Qt, but not designer before)

Best of all it's free and cross platform.

BTW, Access to files/sockets/threads and a host of other things (including GL) are included so you can do all of this cross-platform with just a source recompile.

Good stuff...

Brian

It's not the language that'll take time to learn

[Captain Kangaroo]

It's the set of libraries that will really take time to learn. Seriously. An int is an int in Java, C, and Obj-C. But how do you structure your application? What call do you make to turn your window blue? And what's the right way to get text to show up in the typeface you prefer (or better yet, in the typeface the user prefers?)

Answering any of these questions depends on the API you choose to use. If you know Swing already then you'll get bits on the screen a lot faster than if you decide to learn Obj-C and all the Cocoa Frameworks. On the other hand, if you're starting from scratch on all of them and you don't have any portability concerns then go for Cocoa -- you'll get going quickly and you'll love the result.

Oh Great!

[Anonymous Coward]

Does that mean I can fire all my 2-8 year C programmers and replace them with 1 week C programmers because they will obviously have mastered all there is to know about the language?

Most C prorammers that I have met never exploit the full power of the base language (or even know that you can do things like pointers to functions) much less the standard library. And don't even get me started on the standard library. Every major C project that I've worked on has had a 'system("rm somefile");' somewhere in the code because some dipshit couldn't be bothered to look up unlink. And these are experienced, "professional" programmers.

And they still haven't figured out everything you can do with C++ yet, despite the fact that it only adds "a few more keywords." I've seen a turing machine and a set of LISP keywords implemented completely in templates.

There *is* a good reason for java cocoa

[pHDNgell]

I also thought that it was pointless to create a native application using java, but then, out of necessity, that's exactly what my first OS X application ended up being.

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. :)

Cocoa

[Tar-Palantir]

I have to tell you, I LOVE Cocoa/Objective-C. There are a million benefits to both - Cocoa ( in combination with Interface Builder) gives you fantastically easy GUI creation and control.
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.

PowerPlant from CodeWarrior

[DuckWing]

Use CodeWarrior's PowerPlant. It's a full C++ framework that will let you code to Naitive OS X. CodeWarrior is put out by Metrowerks so see the link for more details.

C#

[daveschroeder]

Of course, MS will claim that C++ did get better with C#...

Re:C#

[Anonymous Coward]

heh, C# is Java++, not (C++)++ ... I wouldn't mind using C# on the Mac though...

Re:C#

[BitGeek]

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.

Re:C#

[fault0]

> C# is already dead. It would be stupid to write applications in it.

Not true at all. Microsoft has said that the future of the windows platform is .NET. Because of this, I've seen many MFC (probably the most used graphical API), switch to C# and Windows.Forms once they switched to VS.NET, bypassing MFC7. Conversly, I've seen many VB developers bypass VB.NET for C# (the two are quite similiar anyways).

The only people who won't switch anytime soon are people who have huge codebases using MFC or plain win32 or win32-based internal API's (which companies such as Adobe use).

However, Microsoft has assured the success of C# pretty much by most other windows programmers by making managed C++ really quite a kludge (and slow) compared to managed languages such as C#, VB.NET, or MFC with C++ (or win32 and C).

Re:C#

[Anonymous Coward]

Don't confuse C# the language (which is in the hands of a standards body) with the other .NET junk. Ironically it's more open than Java at this point. C# that compiles to native code would be nice to have for any platforms, and an alternative to Java.

Re:C#

[BitGeek]

Yes, except that developers for the microsoft platform are the MINORITY, not the majority.

Yes, MS has a large installed base and a large part of one segment of the market-- but the rest of the industry is not going to adopt C#.

The language is DOA. The only question is will it destroy microsoft in the process, or not.

my experience

[g4dget]

Unfortunately, there really is no ideal solution.

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 (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, 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. 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.

I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.

Re:my experience

[bnenning]

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.

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.

Re:my experience

[g4dget]

"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.

Objective-C/Cocoa's reference counting scheme requires manual intervention--if you forget a step, it either leaks or crashes. Furthermore, its strategy often hangs on to memory longer than it needs to. And Objective-C does not have the language constructs to let library implementors automate memory management.

C++, in contrast, does let you automate memory management: you can build class libraries that automatically reference count or garbage collect with no user intervention. They also behave correctly automatically in the presence of exceptions.

Java, of course, automates this completely.

"I don't see much of a future for Cocoa, at least in its current form."

Apple does.

Yes, and I think they are wrong. I mean, come on, do you really think that the world is going to switch to a proprietary widget toolkit from the 1980's? Even if it were every bit as great as Apple marketing claims it is, I don't see that happening.

Let's hope they come to their senses before this really hurts them--it would be nice to have at least one alternative to Windows in the commercial world.

Re:my experience

[Art Tatum]

Apple has made no moves to standardize it or open it up, so it is Mac only.

Evidently, you have never heard of OpenStep, which NeXT and Sun released as an open standard in 1994. From which, of course, GNUstep was derived. GNUstep, being a GPL'd implementation of OpenStep (and tracking changes with Cocoa), offers a Free set of Cocoa frameworks for UNIX systems (Linux, BSD, and so on) and even Windows.

Forgot the link

[DuckWing]

The link didn't work right. so here it is again. Metrowerks

COCOA COCOA COCOA! (and here's why)

[davidmccabe]

First off, the Swing Thing isn't a thing like Cocoa in terms of look-and-feel. It looks-and-feels awfully second-class on many levels.

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.

Here's a choice nobody's mentioned yet. . .

[Farley Mullet]

Hypercard!

Re:Here's a choice nobody's mentioned yet. . .

[Anonymous Coward]

Actually for a lot of quick and dirty stuff, I find that building the GUI in FileMaker and using it's ties to AppleScript ( and thus shell scripts, PERL and PYTHON) makes for good solution. It's not HyperCard, but it's a workable subsititute in a pinch.

Cocoa with Objective C. Its the only way.

[BitGeek]

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:How about Qt/Mac + Designer

[Anonymous Coward]

You've obviously never used Interface Builder then.... :)

A highly capable GUI editor for Carbon & Cocoa applications, it outputs a .nib file (NeXT Interface Builder) which contains a "freeze-dried" set of GUI objects linking targets and actions (the equivalent in QT would be slots and signals) to a set of proxy objects, typically controller and delegate classes in your code. IB can also generate the headers for those controllers and delegates.

'Sounds like Designer', I hear you say. WRONG! QT needs to recompile if you change the interface as you have to resave from designer and then use MOC to regenerate classes and so on. The IB NIB is a binary file containing working objects - in fact you can test a working GUI from within IB including working targets and actions such as a text field getting values from a slider without a compile. With this decoupling you can change the GUI of an interface, including targets and actions, without needing a recompile OR EVEN THE SOURCE CODE. People have found hidden code in Apple apps just by loading the NIB files from applications such as iPhoto, adding buttons and reconnecting actions.

It's incredible powerful, leading to dynamic coupling of GUIs, easy i18n support through automatic language NIB loads and very rapid application development.

I've used QTDesigner and IB and there really is absolutely no comparison. One feels like a piece of shareware compared to the other, and I think you can guess that I don't think IB is the cheapseats.

How am I a troll?

[wray]

Why in the hell am I getting modded down for this? I was only trying to point out that there is a really nice option for those who have some money to pay for the developer license of QT for mac. I use QT as my main development for linux and have been very pleased -- good grief moderaters, READ THE COMMENT.

Re:How am I a troll?

[fault0]

You were probably marked down as a troll because of:

> because the developer license costs money for Mac OSX

Now, the moderator probably interpreted this as "A developer license for MacOSX costs money", instead of "A developer license for the MacOSX version of Qt costs money". The first is true, and the latter is not.

I wouldn't say Java-Cocoa is worthless.

[BoomerSooner]

Probably because that is the reason I decided to support mac development. My apps need a common code base (since they are for linux, windows and mac os x) and java is the easiest way to go. Custom UI, standard classes.

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.

Re:I wouldn't say Java-Cocoa is worthless.

[Art Tatum]

You do realize that Cocoa is portable, right?

Re:Mozilla != MacOSNowis

[Fished]

I have to wonder - what version of Mozilla are you basing this on? I am running Netscape 7 as we speak, and it seems quite snappy to me. As far as environmental bloat .. that seems to be true of virtually all the environments out there nowadays. Looked at .net lately?

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:anal cox

[BitGeek]

Microsoft only has %40 market share. Linux has %10, and the various Mac OS versions have the remaining %50.

Get your facts straight!

PS- for the impaired, my point is to point out that the %95 number is just as fabricated as the numbers I gave.

I don't have upwards of $1500

[yerricde]

>[Qt is fully GPL] Only when compiling for the X11 target

Not if you purchase a license! Qt is well worth the money!

Only if you're in a for-profit business. Qt/Mac will expire after 30 days. Most hobbyist developers (such as myself) don't have upwards of $1500 for a widget set. And according to this FAQ entry, Trolltech releases Qt Free Edition only for operating systems that are free software. Thus, Trolltech will not release Qt for Windows until ReactOS is complete, nor Qt for Mac as free software until GNUstep is complete.

Re:I don't have upwards of $1500

[markalanj]

This is true!

Re:anal cox

[Anonymous Coward]

dream on fella....

Re:macintrash

[BitGeek]

I think you represent the average linux user.

No reason for indecision

[zieroh]

Objective C takes about 10 minutes to learn. Maybe a day to become fluent. Not wanting to use Cocoa because of Objective C is silly.

Do learn Obj-C / Cocoa!

[Anonymous Coward]

Just give it one day. If you know Java, C++ or maybe Smalltalk, Obj-C is _not_ hard at all. Sure, it will look weird for maybe two hours, but after that... believe me, it feels like riding a bike.

Now, ocoa frameworks are rather large, but not at all difficult if you already know the Java framework or any other advanced OOP framework.

Cocoa and the tools are very nice to code in, and learning it is really fun. And, coding in Cocoa is almost as fast as Apple claims it to be. Easily 2-5 times faster than any language / RAD-tool I ever worked with.

Go for it! It is eeeeeasy!

Semi interpreted language

[buserror]

All crucial userland APIs on OSX are written with at least a plain C API. They might be C++ inside (CoreFoundation, CodeAudio, MIDIServices) but they still are presenting C APIs to the OS.

The IOKit is embedded C++ (no multiple inheritance etc). The BSD stuff is plain C of course.

Carbon is a set of plain C APIs. Lots of stuff inside is C++, but well, the APIs published as C.

Now there is cocoa. Objective-C + Cocoa is a semi interpreted language. Calling Cocoa "Native" is like calling Java bytecode "native". Cocoa is not JUST Objective C. Objective-C describes the syntax changes and grammar relative to old pre iso99 C, Cocoa is a runtime it sits on plus a class library. Runtime that is MUCH larger than a C++ runtime, it has to analyze and runtime-link lots of stuff to get working.

So, yeah, writing apps in Cocoa is easier (if you don't want to stray) however the result is also quite slower than the same equivalent statically linked C/C++

Cocoa is strikingly similar to Qt -the messaging system is a large strength in both-. We also know that "lets send messages all around" approach leads extremely quickly to unmaintainable code, in both Qt, and Cocoa.

Cocoa-Java not documented?

[Phil Ulrich]

It's got full documentation on developer.apple.com, just as Cocoa does. They're even the same documentation - but you can choose to view either rhe Cocoa version of a class, or the Java version. For the most part, the classes have the same names, the same functions, but you just use either the Java or Cocoa documentation. The only real reason to use Cocoa-Java over Cocoa, in my opinion, is the fact that if you've already got Java classes you'd like to integrate - like, say, the Helma XML-RPC classes, which beat the arse off Apple's XML-RPC [which tends to miscode things] - then it's easy to import those and use them.

Then again, it's your call - it depends on what you already know, and what you'd like to learn.

Delphi for OS X

[certsoft]

Would actually get me to buy an Apple, but it will never happen.

Cocoa and ObjC.

[BitwizeGHC]

Unless you're planning for compatibility with MacOS 9, Objective-C and Cocoa are the language and API you should be using. The Quartz API is far more robust and does a lot of things better (e.g., rendering fonts) than Carbon does. Java Cocoa programs tend to have a huge memory footprint simply because Java comes with an enormous framework of classes that needs to be linked in.

Carbon also has the disadvantage of being a bitch to program. I think I'd rate Win32 and Classic MacOS API's (which is what Carbon is) as bing at about the same level of difficulty to program in. Objective-C isn't all that bad: it's like C with Smalltalk grafted in. Once you pick up the basic syntax, writing graphical applications using Cocoa is a breeze. The Developer Tools CD comes with everything you need, including compilers and full API documentation. Consider it a fun learning experience.

Java on OS X is "a first-class citizen"

[Anonymous Coward]

Has anyone read yet the cover story article in this month's Java Developer's Journal by Ian McFarland, president of Neo Ventures Ltd., a software consulting company in San Francisco, and author of Mastering Tomcat Development, available in September from Wiley?

The article's called "Building Installers for OS X" and McFarland writes that Java on OS X is "a first-class citizen."

A Java developer since release 1.0 alpha 2, McFarland apparently also maintains www.javaosx.com.

Re:I recommend . . .

[Tim Browse]

My theory is that all Windows developers code for money

Proof by counterexample: I write free programs for Windows - so do a few thousand others, the last time I checked.

Ooh, that was easy! Give me another one! :-)

Tim

Java on OS X is "a first-class citizen"

[Anonymous Coward]

Has anyone read yet the cover story article in this month's Java Developer's Journal by Ian McFarland, president of Neo Ventures Ltd., a software consulting company in San Francisco, and author of Mastering Tomcat Development, available in September from Wiley?

The article's called "Building Installers for OS X" and McFarland writes that Java on OS X is "a first-class citizen."

A Java developer since release 1.0 alpha 2, McFarland apparently also maintains www.javaosx.com.

What a strange question.

[Alien Being]

Don't write to the OS, write to the customer's requirements. If you *must* write to the OS, do what the vendor tells you, else they will cut off your oxygen when you can least afford it.

Unless it's GUI/multimedia intensive, it should be possible to pick an API that you and your customers can easily move to other OSes and other hardware.

What does Apple use? Cocoa + Objective-C

[Olentangy]

Ask yourself, what framework and language is Apple using to create their iApps for Mac OS X?

The answer is Cocoa and Objective-C. You should too.

Get one of the books that have come out about Cocoa (hmm, they all use Objective-C as their language, wonder why?) and spend a week or two familiarizing yourself with it. You'll be building useful code in no time.

One of the best aspects of Cocoa/Obj-C is that it's perfect for wrapping chunks of plain C or even whole Unix command line programs. Apple's develolper web site has a few examples of doing this.

Carbon is a fine API - if running on Mac OS 9 is important to you or you have a large existing base of classic Mac OS code to bring to Mac OS X. Otherwise, there is no real point.

I've been a Mac programming for a dozen years and switched to Cocoa/Obj-C a year ago. I'm more productive than I've ever been before and am having more fun doing it.

Enjoy!

Re:What does Apple use? Cocoa + Objective-C

[lrivers]

Of course for unimportant apps, like say the Finder, they use Carbon.

Re:What does Apple use? Cocoa + Objective-C

[Olentangy]

Right, but the Finder was a PORT from Mac OS 9. So of course they used Carbon. That's what it's for.

Expect to see a Cocoa based Finder next time they rewrite it.

Objective-C and Cocoa are very easy to learn....

[borgheron]

and also very elegant once you get used to them. Cocoa, Apple has stated, is the preferred programming API on Mac OS X. Objective-C is the best way to use it. As a former NeXTSTEP/OPENSTEP programmer and a current GNUstep contributor, my advice is to try it. :)

For more information about GNUstep, go to:
http://www.gnustep.org

The site also contains a plethora of information about Objective-C, OpenStep, and Cocoa.

Later, GJC

Re:I recommend . . .

[lemkebeth]

That was a general rule.

Every rule has exceptions.

Mind you there are some decent free apps for windows (never said there weren't) but, there are fewer of them than on alternative platforms (free ones that are decent).

HTMLkit for example is a free Windows HTML editor.

On the Mac, there is a lot of freeware utilites and other things and the same freature set will cost money under Windows.

Basically it is a matter of numbers.

Re: wooly-headed thinking (OT)

[Anonymous Coward]

I always wondered about that, how conservatives and liberals can each see the other as "wrong-headed," and self-evidently so.

Is it just a case of overgeneralization, i.e. if you understand the motivations of people like yourself, you believe they are the same for everyone else? One size fits all?

That's why I prefer to argue from facts! :)

porting

[captaineo]

What I'd really like to know is, what would be the best API for porting a large existing program to Mac OSX?

Say I have a medium-to-large C or C++ program. Currently it has a Windows GUI (using MFC or straight Win32) and an X GUI (using Gtk or Qt). Now I want to port it to OSX, taking as much advantage of existing code as possible. What API do I use?

(e.g. I am excited about all the possibilities of Cocoa, but is it really that easy if the core program is NOT OSX-only?)

Tools?

[splattertrousers]

I currently use IntelliJ IDEA to write my code, because it saves me tons of time with its smart code completion and refactoring features.

It looks like Eclipse doesn't support Objective C, though it apparently supports Mac OS X now.

Are there any other good tools for developing Objective C apps on Mac OS X (other than Project Builder and CodeWarrior)?

Cocoa !

[thomasdeniau]

There's no debate, the answer is Objective-C/Cocoa. It's definitely easy to learn, in three months you will be able to make great software using it.

Fairly simple!?

[rjrjr]

Your implication that Cocoa can't handle a complex GUI is ridiculous. Sputter, fume...words fail me.

rjrjr

Re:Fairly simple!?

[statusbar]

No I did NOT imply that Cocoa can't handle a complex GUI application! My comment was not ridiculous! I have found that most applications are often eventually desired to be easily portable to other platforms. Hence the suggestion - Write the core code in a portable c++ library, and do the simple gui on Cocoa. Then for windows, use the same c++ core code library and a win32 gui. For linux, use the same c++ core code library and a gtk or qt gui.

Most applications that I have written have been requested for platforms other than I wrote them for. Either write your code with a portable gui toolkit, or cleanly seperate your core code from the gui so you can port the application easier!

--jeff++

Re:Fairly simple!?

[rjrjr]

Ah, point taken. It wasn't clear to me what you were driving at.

Me, I'd be more inclined to go the portable core/native UI route, but it you're right, it would have to add up to more work with each additional platform.

Re:Fairly simple!?

[statusbar]

Yeah, my original message wasn't that clear! Sorry.

--jeff++

Qt

[e8johan]

I must recommend Qt. You'll get neat code, portable to Win32, X-windows, BeOS, etc. Get it from Trolltech!

A better question is...

[anarkhos]

whether the interface of your app is going to SUCK.

The NeXT APIs are easier to develop for in my opinion, however speaking as a user I have yet to use a Cocoa app I like. Nearly all apps I use in OS X are Carbon. This is mainly due to the schizophrenic nature of OS X which I believe will only improve if Apple makes the Aqua HI Guidelines more specific. I don't think NeXT even had guidelines, but rather (falsely) assumed the API abstraction would take are of this.

Comparing SimpleText (Carbon) with TextEdit reveals most of the differences (and most of the reasons Cocoa apps get on my nerves, like the behavior of NSLayoutManager).

You should also consider PowerPlant which I still use.

I would also add that Apple shouldn't have adopted Swing unless they could convince Sun to make the API more platform neutral. Don't use it.

Re:I recommend . . .

[Tim Browse]

That was a general rule.

Every rule has exceptions.

So what you actually mean is, instead of saying this:

My theory is that all Windows developers code for money

You should have said this:

My theory is that most Windows developers code for money

as it's more accurate. And probably less contentious.

On the Mac, there is a lot of freeware utilites and other things and the same freature set will cost money under Windows.

Hmmm....I think I feel another exception coming on... :)

Tim

Cocoa and carbon -- bitter enemies to the end

[inkswamp]

For those curious about the Cocoa/Carbon debate

I have to confess I don't fully understand this perceived dichotomy between Carbon and Cocoa. I've been doing Macintosh programming since system 7.x and I've recently gotten into Cocoa. There were some fears initially that I wouldn't be able to use any of the code I'd written previously, but that fear was allayed with this:

#import <Carbon/Carbon.h>

I can bring the Carbon headers right into any Cocoa project or object and then drag over old code. No biggie. (Although for the record, it's not 100% backward-compatible. You do have to tweak things a bit.)

I'm not sure that Apple ever intended Cocoa and Carbon to be rival approaches, but rather complements--that's how I'm using them. Still, this perception exists.

GUI framework for OS X

[Crazy Viking]

Hey, if what you are looking for is a GUI framework for OS X then you should look no further than QT. It is C++ and cross platform source code compatible (Linux, unix and windoze).

If time was money we should all sit around waiting to get rich.

Stay far far away from Swing

[forgoil]

Not only is it horrible, but it is also about as slow as anything ever has been.

I suggest going with a native interface, and if you don't want to do ObjC do C++ and separate the logic and the display. Don't try too hard to get something portable, that will work against you. Concentrate on making a good piece of software and code clean and easy to understand C++. It will be much easier to port it if you have a good design.

Re:I recommend . . .

[Calibax]

Truth hurts, doesn't it, fanboys? If it isn't true, explain to me why what are free utilities for Windows machines are $20-$30 extortionware for the Mac.

ummm, well, that's a new one. I live daily in a mixed world of Windows, Macs, and Unix systems. Yes, you might be able to find the occasional product that is free under Windows and not free on the Mac, but honestly I would place the likelihood somewhere around the same level as pigs flying out of my arse every Saturday evening at 11pm.

I suggest you install Windows XP and place a DVD in your player. Then read the dialog telling you about companies that will sell you a suitable product to play that DVD thoughtfully provided by Microsoft. Of course, on a Mac, Apple just provided the application to play it.

The general rule is for everything to be shareware or a product on Windows. I have come across approximately zero free products that I would want to use. I daily use half a dozen products that people have written and made freely available on the Mac, or have been provided with the Mac operating system and are extra cost items under Windows. And let's not forget that the Mac OS is a lot less expensive than Windows XP despite providing more capabilities.

Cocoa, Carbon, Java - a strange brew!

[Jezza]

Cocoa OR Carbon - you don't actually need to choose. You can use both - if you have lots of old Mac code (I assume this isn't the case) then Carbon has a lot of offer. You can write new applications with it but this is a reworking of the old Macintosh Toolbox, so it isn't the most productive environment available (though Apple have made sure that everything works well in the developer environment).

Java, if you're using Java and Java Swing - you're not using the Cocoa environment at all. Programs written here are just like those written on other platforms. These programs are portable to other Java2 SE implementations. That's the point.

Cocoa, is written in Objective-C and "bridged" to Java2. (Java is actually based on the Objective-C programming model - so says Sun's Java Whitepaper, so it's quite a natural match) You can program against Cocoa in both Java2 and Objective-C.

A word on Objective-C, if you know C and you understand OO then you can learn Objective-C in an afternoon. Objective-C is C with OO - nothing more. Where C++ is C with everything including the kitchen sink and loses the essance of C (small is good) Objective-C is simple like C, and adds very little to the base language. Because Objective-C is based on ANSI C it can also be added to C++; this is known as Objective-C++. You might want to use Objective-C++ if you want to reuse existing C++ code (a good reason).

I think it's worth stating again, Objective-C is easy to learn, is available where GCC is (pretty much everywhere) and is a small programming language that is very productive. Personally I think this is worth the afternoon you'll spend learning it. The syntax of Objective-C is simple and elegant (unlike that of C++). Objective-C is not strongly typed like Java, and considers the "nil" object to be able to respond to any message (it simply returns nil). These two aspects make for much cleaner, simplier looking code. And it's real - big applications have been written with Objective-C - put simply: "It worked for them, it can work for you".

So if you're totally new the programming the Mac, I'd advise you to concentrate on Cocoa with Objective-C, learning the Cocoa framework is the big part of the effort, not Objective-C. You'll find that Objective-C makes the job (of learning those frameworks) much easier. This is the most productive development environment there is on any platform.

If you need to use Java2, feel free - either using normal Java2 technologies like Swing that'll run on other platforms that support Java2 SE. You can also use Java2 to write to the Cocoa frameworks, and this can be worthwhile if you have a reasonable amount of Java2 code you wish to use.

If you need C++ then Objective-C++ is perfect, you can use existing C++ code in your Cocoa projects. You can also mix Java2 in, in the normal way. Again useful if you want to leverage existing code.

Cocoa and Carbon can also be mixed more easily in the current release, this is especially useful when you want to make significant extentions to existing Macintosh applications using the more productive development environment of Cocoa.

Also of note is Apple's WebObjects, the current release is 100% Java2 and provides the ability to write web based applications, Java2 client applications and applets and also Cocoa/EOF applications that have significantly easier database access through EOF. (EOF uses JDBC to connect to the database so support for modern RDBMSs shouldn't present a problem).

I hope this helps :-)

C++ and Qt

[master_p]

...is the best combination. With few lines of code you can create beautiful user interfaces in the snap of your finger. It is as easy as declaring one widget into the other, starting from QMainWindow.

Qt is available for Mac. You gain 100% portability to Windows and Linux. It provides very nice C++ primitives for IPC communication (QProcess).

Generally, you will not need anything else, if you touch Qt.

F-Script for interactive Cocoa fun!

[Anonymous Coward]

A nice complement to Cocoa Objective-C is F-Script, an interactive environment for easy exploration and scripting of Objective-C objects.

It's open source, graphical, easy to use and quite fun.

TRY SWT from IBM. It is cross-platform too:

[croanon]

It really works very fast! It is like SWING, but uses OS's native GUI. Mac OSX version is just released. Also, you can use Eclipse open source IDE, which is available on all the platforms, and the best IDE that you can find around. It supports refactorings, and has a terrific plug-in structure. There are 100s of plug-ins ready to be used already. Check out : www.eclipse.org

SWING is NOT the only choice. What about SWT?

[croanon]

SWT is from IBM. Try it. It is really fast GUI framework for Java, it is cross platform, and it really rocks! www.eclipse.org

Re:SWING is NOT the only choice. What about SWT?

[Twirlip of the Mists]

SWT suffers from exactly the same flaws that doom Swing. It's ugly, and user interfaces created with it are unpleasant to use. It looks like exactly what it is: a user interface designed and built by a UNIX user with no particular concern for the overall user experience.

No, thanks. I'll stick with Aqua. That way I can use a computer without feeling like I want to claw my eyes out at the end of the day.

As a long time mac user and programmer...

[Anonymous Coward]

Go with Carbon. Why?

-Your apps will run under OS 9.
-You can write in C. (I personally much prefer C to objective C, and there are more C compilers than objC ones if you're targetting other OSen)
-The library is very similar to Quickdraw, if you've done mac programming before you have to learn pretty much nothing

If you're starting from scratch knowing NO APIs, NO programming languages, and using ONLY OS X, then go with objective C and Cocoa. Otherwise, Carbon is just a better choice.

Check out wxWindows

[Anonymous Coward]

You might want to check out wxWindows. You can find it on http://www.wxwindows.org.

It's a cross-platform GUI (or all-around) C++ library that works on Windows, Linux (and then implements either Gtk+ or Motif), Mac OS X and I think a few others.

It's easy to learn although it may feel a bit weird at first.

However, if you're not interested in (true) cross-platform functionality, then you might as well go with Carbon/Cocoa in C++/Obj-C/Java. :) When I say true cross-platform functionality I mean using each OS'es native interfaces... when compiled on Windows, it's a Windows app. When compiled on Linux, it's a Gtk+ app and so forth.

I've been able to compile all my code on all three platforms without any significant problems (and all of those problems have been to my lack of knowledge), always using GCC (which ships with Mac OS X and Linux, and is available with the MingW and Cygwin packages on Windows).

Hope you like it. I sure do. ;)

is OS X open source?

[willigis]

I am a nontechnical businessman and I have a question about OS X. YOu seem to be knowleadgeable about this matter. so perhaps you can help me clarify one question. Is the source code for OS X available for licensing? Is it open source? is it published? I ask this because OS X derives from Unix and Next and must be related to Linux. I think it has a beautiful GUI and network capabilities and it would be fun (and profitable) to port OS X to other microprocessors, outside of the APPLE/Power PC niche. Apple will never do it themselves. Thanks in advance

Re:is OS X open source?

[cbv]

Is it open source? is it published?

No, but GNUstep is.

Re:is OS X open source?

[Art Tatum]

Part of the operating system is (Darwin). But all the graphical stuff you see is not. It is not related to Linux, it *is* related to Mach and BSD. Darwin already runs on x86. Furthermore, if you need to have your Mac OS X applications run on other platforms, you can use GNUstep, but you'll have to avoid QuickTime (patent issues) and some things that are only partly implemented in GNUstep currently. After that, you can run Cocoa applications on other UNIX systems (like Linux, *BSD, HP-UX) and in the future, Windows (there is a Windows graphics backend, but it's in an alpha state).

Re:is OS X open source?

[willigis]

Dear Art:
Your answer was very clear. Also a previous answer pointed to Gnu. Let me play back what I understand.
1) OS X is not open source
2) GNU step can be used to run OS X applications on other UNIX platforms, but not Windows yet.

The graphical stuff in OS X is proprietary to Apple.

I just do not understand what exactly is GNU step. Is it a language, a complier, an operating system, an emulator? Excuse my old fashioned language, but I am not an IT person!
Thanks
GS

Re:is OS X open source?

[cbv]

GNU step can be used to run OS X applications on other UNIX platforms, but not Windows yet.

No. GNUstep can be used to write applications that can be compiled - and run - on MacOSX. Getting GNUstep to work on Windows is in progress.

I just do not understand what exactly is GNU step. Is it a language, a complier, an operating system, an emulator?

It's an API (Application Program Interface), a collection of libraries, header files, ... based on the original OpenStep specification provided by NeXT, Inc. (now Apple), in a way somewhat similar to Qt or GTK. You can use GNUstep to write portable applications for a variety of different hardware platforms, that either have GNUstep, or NeXT/OpenStep, and even MacOSX installed. A good example would be GNUMail.app.

Re:I recommend . . .

[lemkebeth]

"most" is indeed what I meant.

Mono/gtk#

[Anonymous Coward]

How about using c# and gtk see www.go-mono.com

Its in its infancy now, but it will be great :O)

Re:Use Objective C + OmniNetworking

[Art Tatum]

And one more reason: OmniNetworking has been set up to build with GNUstep. Write your Cocoa app in Objective C, write some makefiles for GNUstep, run your Cocoa app on Linux, BSD, HP-UX, etc. You might want to use GNUstep's IB and PB clones for development, however, since it's easier to go from GNUstep to OS X, than vice-versa.

Re:How about Qt/Mac + Designer

[Anonymous Coward]

I've used both and actually Qt supports dynamic loading of gui files too, the obvious example being the designer that loads .ui files, and allows testing of them without requiring that those .ui files be compiled into source.

The designer isn't special, other apps can do this too, just use QWidgetFactory. But for some reason this isn't very popular amongst Qt application developers, I guess they prefer to work directly with c++ classes rather than work indirectly through resource/NIB/.ui files.

Let the punishment fit the crime

[iPaul]

Basically, having to slog through yet another API/Language can be considered a punishment, so let it fit the crime you want to commit (program to write).

Question 1: Am I going to port this application to lots of other platforms? Java's a good choice because Cocoa or Carbon are both platform specific. Other options include some other GUI toolkit, like QT, and cross-platform IDE's like RealBasic.

Question 2: Am I going to use a lot of APIs available only in [insert your language here]. For example, say you have a large transaction processing package written in Java, and that's a must-have in your application. That will probably dictate the language. Likewise, if you will need to use very Mac specific C api's Cocoa, Carbon or some toolkit like QT is a good idea.

Question 3: What kind of a programmer are you? Do you squirm every time someone talks about pointers? If so C, Objective C, and C++ are probably going to give you head-aches. Java is kinder, but other languages like RealBasic or Apple Script avoid the issue entirely.

Question 4: Are you doing this to entertain yourself? It's great to have hobbies and the best part about hobbies is that you can choose to use whatever strikes your fancy.

Question 5: How much work do you have to do? If you know Java very well, you know swing, and you're using a lot of Java API's it would be a lot more work to learn some other toolkit. Or if you have 5 years of VB experience then RealBasic might be a simple transition.

Question 6: How important is the GUI Part of the user experience? On a commercial app for non-technical users, a crisp GUI that's consistent with the platforms Human Interface standards is vital to the success of the product. In this case native toolkits like Cocoa or Carbon are your best choice. If the user is a sophisticated user that is more concerned about your application correctly doing what it's supposed to do (like amortizing loans) a slower, less native GUI might be ignored in favor of correct program behavior.

I don't think Objective C is especially difficult to learn, although it takes some investment to understand the Cocoa framework. It also takes time to learn the Carbon framework or Java Swing if you don't know it. If you're new to programming I'd suggest you take Real Basic for a spin (it's free to try out).

If you're writing an application for the mac and you don't care about other platforms then use Cocoa. Carbon is a bridge provided so that applications can be moved from Mac OS 7/8/9 to X. Anything you can do in C you can do in Cocoa, if they don't already have an objective C api for it.

If you're writing cross-platform applications I suggest you isolate your application logic in libraries with which you link. They can be in Java or C, and try to make it as independant as possible from the UI code. I haven't seen a lot of Java Applications do all that well in the market place but that may or may not be important. Generally successful, commercial apps use native UI code and platform independant library code.

Gnu Step

[willigis]

Very Clear. Thanks. GS

Coca, Carbon and Java

[Anonymous Coward]

There is a way to combine the three:

Burnt Chocolate Coffee.