Please create an account to participate in the Slashdot moderation system


Forgot your password?
Apple Businesses

Which Coding Framework for Mac OS X ? 334

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

Which Coding Framework for Mac OS X ?

Comments Filter:
  • You also have Carbon (Score:5, Informative)

    by akac ( 571059 ) on Sunday October 13, 2002 @02:13PM (#4441282) Homepage
    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
  • by Clock Nova ( 549733 ) on Sunday October 13, 2002 @02:14PM (#4441286)
    I'd go with Cocoa. The more native, the better.
  • Don't use Cocoa (Score:0, Informative)

    by jpmorgan ( 517966 ) on Sunday October 13, 2002 @02:15PM (#4441295) Homepage
    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. :)
  • learning objective c (Score:5, Informative)

    by Dougal ( 1492 ) on Sunday October 13, 2002 @02:16PM (#4441298) Homepage
    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.
  • Cocoa all the way (Score:5, Informative)

    by petrilli ( 568256 ) on Sunday October 13, 2002 @02:17PM (#4441308) Homepage
    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:Don't use Cocoa (Score:4, Informative)

    by WoofLu ( 459652 ) <> on Sunday October 13, 2002 @02:18PM (#4441310) Homepage
    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.
  • by zulux ( 112259 ) on Sunday October 13, 2002 @02:21PM (#4441328) Homepage Journal

    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.

  • by hoegg ( 132716 ) <> on Sunday October 13, 2002 @02:22PM (#4441334) Journal

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

  • by T-Kir ( 597145 ) on Sunday October 13, 2002 @02:26PM (#4441346) Homepage

    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!

  • by Anonymous Coward on Sunday October 13, 2002 @02:31PM (#4441368)
    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. ;)
  • by Anonymous Coward on Sunday October 13, 2002 @02:33PM (#4441376)
    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):
  • Re:Don't use Cocoa (Score:3, Informative)

    by Twirlip of the Mists ( 615030 ) <> on Sunday October 13, 2002 @02:37PM (#4441389)
    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.
  • Cocoa / Obj-C (Score:5, Informative)

    by Sahib! ( 11033 ) on Sunday October 13, 2002 @02:39PM (#4441400) Homepage

    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 []?

  • How about Qt/Mac (Score:3, Informative)

    by SilverSun ( 114725 ) on Sunday October 13, 2002 @02:42PM (#4441414) Homepage
    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
  • Java Cocoa (Score:5, Informative)

    by BlueGecko ( 109058 ) <(moc.liamg) (ta) (kcallop.nimajneb)> on Sunday October 13, 2002 @02:43PM (#4441418) Homepage
    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 if they are part of the ObjC FoundationKit and part of 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.
  • by Twirlip of the Mists ( 615030 ) <> on Sunday October 13, 2002 @02:43PM (#4441420)
    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 [] 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:What about QT? (Score:2, Informative)

    by SilverSun ( 114725 ) on Sunday October 13, 2002 @02:47PM (#4441438) Homepage
    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.
  • by malice ( 82026 ) on Sunday October 13, 2002 @02:48PM (#4441442) Homepage
    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.

  • by Anonymous Coward on Sunday October 13, 2002 @02:50PM (#4441449)
    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:Cocoa / Obj-C (Score:2, Informative)

    by Sahib! ( 11033 ) on Sunday October 13, 2002 @02:52PM (#4441457) Homepage

    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:

  • by jarrettwold2002 ( 601633 ) on Sunday October 13, 2002 @03:00PM (#4441489)
    I myself just got into OS X development. I found that the doucmentation for ObjC is huge, almost all examples I find are in ObjC. Also there is a nice BSD sockets wrapper from OmniGroup calld OmniNetworking. SX /Frameworks/

    In addition there is a mailing list that's amazing and answers a ton of questions that link is:

    Finally as intimidating as ObjC looks, it's quite easy to pick up after you get the basics down. I would highly recommend Aaron Hillegass's Cocoa Programming for Mac OS X.

    Finally last reason. It's something to add to your resume. I like programming because of the cool new stuff. It's like a geek Christmas every day. As such why not try the new toys and learn from it. Since ObjC has been in GCC for a while, you can use it elsewhere ;)
  • by Mindcrym ( 52114 ) on Sunday October 13, 2002 @03:01PM (#4441495)
    Check out the article Introduction To and Experiences With Mac Cocoa [] from Kuro5hin.
  • Re:Mozilla (Score:5, Informative)

    by Fished ( 574624 ) <> on Sunday October 13, 2002 @03:01PM (#4441497)
    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.)

  • Only on X11 (Score:2, Informative)

    by yerricde ( 125198 ) on Sunday October 13, 2002 @03:03PM (#4441505) Homepage Journal

    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.

  • Fink? (Score:2, Informative)

    by yerricde ( 125198 ) on Sunday October 13, 2002 @03:09PM (#4441529) Homepage Journal

    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:The Master Of C (Score:5, Informative)

    by Jorrit ( 19549 ) on Sunday October 13, 2002 @03:17PM (#4441561) Homepage
    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.

  • by gnuadam ( 612852 ) on Sunday October 13, 2002 @03:18PM (#4441567) Journal

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

  • Re:Don't use Cocoa (Score:4, Informative)

    by bnenning ( 58349 ) on Sunday October 13, 2002 @03:18PM (#4441568)
    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.
  • by Anonymous Coward on Sunday October 13, 2002 @03:25PM (#4441595)
    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.
  • by bnenning ( 58349 ) on Sunday October 13, 2002 @03:27PM (#4441599)
    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.

  • by RevAaron ( 125240 ) <> on Sunday October 13, 2002 @03:56PM (#4441737) Homepage
    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:Don't use Cocoa (Score:4, Informative)

    by jimbolaya ( 526861 ) on Sunday October 13, 2002 @04:00PM (#4441752) Homepage
    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.

  • Cocoa for sure (Score:1, Informative)

    by Anonymous Coward on Sunday October 13, 2002 @04:08PM (#4441777)
    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.
  • by jimbolaya ( 526861 ) on Sunday October 13, 2002 @04:10PM (#4441791) Homepage
    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:The Master Of C (Score:5, Informative)

    by orthogonal ( 588627 ) on Sunday October 13, 2002 @05:09PM (#4442018) Journal
    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:
    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.
  • Cocoa (Score:2, Informative)

    by Tar-Palantir ( 590548 ) on Sunday October 13, 2002 @05:30PM (#4442091)
    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.
  • C and X Windows (Score:1, Informative)

    by Anonymous Coward on Sunday October 13, 2002 @06:09PM (#4442228)
    Maybe someday Apple will ship a real UNIX, with X Windows included. Until then, users must install XDarwin themselves, but it can be done. And it's free. And it'll make your code more cross-platform compatible than anything Apple currently provides. After all, why should you lock yourself into an expensive, proprietary environment that makes such extensive use of free software?
  • 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.
  • by BitGeek ( 19506 ) on Sunday October 13, 2002 @06:31PM (#4442303) Homepage

    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.
  • by BitGeek ( 19506 ) on Sunday October 13, 2002 @06:39PM (#4442329) Homepage

    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:Cocoa / Obj-C (Score:3, Informative)

    by BitGeek ( 19506 ) on Sunday October 13, 2002 @06:54PM (#4442370) Homepage

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

  • Re:The Master Of C (Score:5, Informative)

    by Frymaster ( 171343 ) on Sunday October 13, 2002 @07:51PM (#4442516) Homepage Journal
    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:Mozilla (Score:3, Informative)

    by Lao-Tzu ( 12740 ) on Tuesday October 15, 2002 @08:23PM (#4457950) Homepage

    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.

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson