Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Apple Books Media Businesses Book Reviews

Cocoa Programming for Mac OS X 300

Posted by timothy from the mixed-barrel dept.
Michael Simmons contributed this review of what he claims is the best of the very few books out there for folks who want to learn Cocoa programming. The field is so small, in fact, that he can give a nutshell review along the way of the only other one he's encountered, O'Reilly's Learning Cocoa. Update: 12/13 15:45 GMT by T : Please note: Simmons is thanked in the acknowledgements of Hillegass' book. He explains: "I went to the Big Nerd Ranch, where the author teaches an amazing Cocoa course. While there, I received a pre-release copy of the book (it's the coursebook, actually.) I had found a bunch of errors and typos, and helped Aaron correct those errors and inconsistencies, so I'm guessing he is thanking me for my contributions to quality." Just to clear that up!
Cocoa Programming for Mac OS X
author Aaron Hillegass
pages 416
publisher Addison-Wesley
rating 8.5
reviewer Michael Simmons
ISBN 0201726831
summary Learn to program OS X applications

Intro to Cocoa
If you're interested in programming for Mac OS X, you've definitely heard of Cocoa by now. Cocoa is the name of the library of frameworks that gives you the ability to write advanced applications with ease. The Cocoa frameworks enable you to perform tasks that used to take a decent amount of code and implement it in a very straightforward manner. The hardest thing about learning Cocoa is that because it's so simple, it takes some getting used to.

You can write Cocoa applications with either Objective-C or Java. If you aren't familiar with Objective-C, it's an extension to the C language that makes it object-oriented. I'm not sure why Apple decided to offer Java support for Cocoa, since almost every source of information on the Internet and all Cocoa resources seem to only refer to Objective-C. Since Java-written Cocoa applications will not run on any platform other than OS X, it was probably done as a marketing "thing" -- Apple is giving Java programmers the ability to program Cocoa applications, opening up the potential for more Cocoa engineers.

Until today, there was only one book if you wanted to learn Cocoa. That book is Learning Cocoa , which is published by O'Reilly and written by Apple Computer, Inc. The new kid on the block is Cocoa Programming for OS X, which is published by Addison-Wesley and written by Aaron Hillegass of the Big Nerd Ranch. With two books out, Cocoa programmers now have an actual choice of which book to buy. Which brings us to the point of this review -- which book is better?

Is it really O'Reilly?
Since Learning Cocoa was out first, I'll start with my analysis of it first. When I heard that O'Reilly was going to start publishing OS X programming books, I was stoked. O'Reilly books have historically been amazing -- very complete and straightforward sources that any programmer would be proud to have in his or her arsenal of knowledge. Unfortunately, Learning Cocoa falls short of the O'Reilly tradition, and makes me wonder if O'Reilly actually supervised the printing of this book.

There are some good points about the book. It was the first and only Cocoa book, so when I got my copy back in May, I was looking forward to learning the language. It does provide some good examples on how to write Cocoa applications, which allows one to dive straight into Cocoa programming. The introduction to Cocoa is really good -- it gives a very in-depth description of Object-Oriented and Cocoa program design, which I really like. Additionally, it gives a very good background to the concepts and techniques of using Cocoa.

However, there is a real problem with this book. This book reads more like it was meant to be an internal reference at Apple, rather than a book for the beginner. Another problem is that the layout and order of the content is confusing. Unlike past O'Reilly books and other quality programming books, it seems like this time they took a bunch of internal technical documents on Cocoa, and sent them to the binding machines without further editing. That the book credits "Apple Computer, Inc." as the author provides good evidence for my theory.

The heart of the problem is that the reader has to really dig and explore through this book to find that info that he or she wants. When learning a new language or programming concept, a book should be easy to follow and it should allow the reader to focus on learning the actual concepts, and not having to figure out the flow of the book.

Aaron hits a home run
The "flow" statement is a perfect segue into my analysis of Cocoa Programming For Mac OS X. Right away, I could tell that I was going to like this book. The author, Aaron Hillegass, wrote this book like he is a friend speaking directly to the reader -- he takes you through each concept like he is right there with you. This book teaches you Cocoa by specifically having you write applications, and in each new chapter, you add new features. As you add each new feature, you'll learn an important Cocoa concept.

O'Reilly's book also has the reader write applications and add features, one by one, but it does so in a very sporadic way. I was never really sure what the purpose of adding a certain method was, whereas with Aaron's book, each chapter is focused on an ordered and very specific concept, making it very clear what I was about to learn, and why.

Another part of this book that I really appreciate is the chapter on Objective-C. In just one chapter, I understood Objective-C. You must already know C and at least one object-oriented language (like C++ or Java,) but after reading this chapter, you will be able to write Cocoa applications in Objective-C.

This book comes with an online counterpart, powered by Techstra. Techstra is an online engine that allows you to enter any page of the book and get "extras." The extras include examples not in the book, solutions, errata, and even input from readers. It's very cool and very helpful.

A final and very strong point of Aaron's book is that it reflects the latest update of the Mac OS X development tools, Project Builder and Interface Builder. Apple just updated the development tools to version 10.1, substantially changing the UI and functionality, and the latest version is reflected in Aaron's book.

Conclusion
It's clear to see which book I'm giving the nod to. I know it appears like I'm being biased towards Cocoa Programming For OS X, but if can get to your local bookstore and actually compare the two books side by side, you'll see why I'm so enthusiastic about Aaron's book.

I think having both books is a good choice, as the O'Reilly book does offer very in-depth information, which is useful once you learn Cocoa using Aaron's book. If O'Reilly changed the title to After Learning Cocoa, I think my perception of the book would be different.

Cocoa allows programmers to write powerful applications in a very short amount of time. I am amazed at the power and simplicity of the Cocoa frameworks, and can't wait to see what myself and other programmers end up creating in the future. I'm sure other books will come out in the future, but for now all we have is two. The one I'd recommend is Cocoa Programming for Mac OS X, but you already knew that. :)

You can purchase this book at Fatbrain. Want to see your own review here? Read the book review guidelines first :)
This discussion has been archived. No new comments can be posted.

Cocoa Programming for Mac OS X More

Cocoa Programming for Mac OS X

Comments Filter:

  • other Mac OS X programming resources (Score:3, Insightful)

    by Frothy Walrus ( 534163 ) on Tuesday December 11, 2001 @11:37AM (#2687439)
    the NeXT Programmer's Manual (by Simson Garfinkel, i believe) is a very useful Mac OS X programming resource (although it doesn't help with Cocoa). the OS X programming environment is substantially the same as the NeXTSTEP/OPENSTEP environment. they're both based in Objective C, and even many of the windowing calls are the same (most of whose names still begin with "NS" for "NeXTSTEP"!).

  • Other (non-book) resources. (Score:4, Informative)

    by hotsauce ( 514237 ) on Tuesday December 11, 2001 @11:43AM (#2687479)

    Two resources I've found useful in Cocoa programming are stepwise.com [stepwise.com] and O'Reilly's Mac Devcenter [oreillynet.com].

  • Wondering which was first... (Score:3, Insightful)

    by rbk ( 527224 ) on Tuesday December 11, 2001 @11:44AM (#2687487)
    Apple's Cocoa or cocoa [unige.it], the computation in commutative algebra system?

    • Re:Wondering which was first... (Score:4, Interesting)

      by RevAaron ( 125240 ) <revaaronNO@SPAMhotmail.com> on Tuesday December 11, 2001 @12:10PM (#2687650) Homepage
      Actually, what came before both of them, I imagine, was Apple's long-lost *other* Cocoa.

      Cocoa was a multimedia authoring environment for kids. Apparently, a pretty interesting one too- a object-oriented IDE for kids, believe it or not. I think Alan Kay had something to do with it while he was still with Apple.

      How I long for the days when Apple would do interesting research! Am I the only one who misses it? (the original) Cocoa, Dylan, MacLisp- a lot of interesting things that they seem to have given up on.

      Actually, it looks like your Cocoa came first- they started calling it that around 1990, it appears.

      Link:
      http://hometown.aol.com/schmucker1/index.html

      • Actually, what came before both of them, I imagine, was Apple's long-lost *other* Cocoa. Cocoa was a multimedia authoring environment for kids.

        Yes, it did come first, but it's not lost! That project was spun off from Apple into the company Stagecast [stagecast.com]. Apple retained rights to the original name. Actually, the earlier name for the project was KidSim [acm.org]. The prime movers for KidSim were David Smith and Alan Cypher. Larry Tesler was Stagecast president. Both Smith and Tesler originally came from Xerox PARC.

  • Apple Developer Connection (Score:5, Interesting)

    by Sahib! ( 11033 ) on Tuesday December 11, 2001 @11:48AM (#2687512) Homepage
    For anyone interested in developing for Apple's platform, the Apple Developer Connection [apple.com] is an indespensable resource. I haven't read the O'Reilly book on Cocoa, but I suspect that, since it was written by Apple, most of the information there can be found, for free, on Apple's site. Apple has provided well-documented APIs, sample code and several tutorials for both Objective-C and Java (despite what the reviewer said, check here [apple.com]). Also, for those who want to develop for Mac OS X, once you have it installed, and the developer kit from Apple (after all, you won't be able to develop without it), you will find that most of the tutorials, API documentation, etc. are on your hard drive. This includes extensive documentation on the changes that Apple made to the BSD development tools (gcc, gdb, ld, ...). In short, my point is that if you are already familiar with programming in C, C++ or Java, you don't need a book to learn Cocoa. The information is all provided for free by Apple.

  • Cocoa will replace Ecstasy... (Score:4, Informative)

    by yunfat ( 200898 ) <taran@@@mac...com> on Tuesday December 11, 2001 @11:50AM (#2687525)
    Well, maybe not, but as a everyday user of OSX its easy to see how Cocoa apps are the future. They interact better with the OS, they seem less bloated, and they just seem tighter. Cocoa apps like Okito Composer [okito.net] are compelling reasons to move to X... it blows away MS Word.
    • Not always. OmniWeb used to seem to hideiously slow and bloated on OS X, compared to iCab and even IE.

      It seems OmniWeb has caught up. Once again, it is my primary browser. And damn- I forgot how sweet pages look in OmniWeb!

      What was my point again? Oh yes. Cocoa has no intrinsic advantages as far as what the user sees- especially considering that Services are being largely ignored. The advantage comes to the developer, who is allowed more time to work on important things in their app, rather than pidly things. But Composer could've been written in Carbon or MFC- it just would've taken a lot longer. ;) (but wait! I suppose that is an advantage for end users!)

      ...and this is coming from me, a NeXTie, who still has a NeXT cube (working MO drive!) and ran OpenStep 4.2 and Rhapsody DR2/x86 on his PC until I finally just bought a Mac a year.5 ago. So, if anything, I'm positively biased toward the Cocoa API.
  • (recipie)

    For each cup:

    Mix 2 tbs cocoa powder with 2 tbs sugar.
    Slowly add 8 oz milk while stirring.
    Heat on stove, but do not allow to boil!

    Add 1 shot of either orange liquer, creme de menth, or Irish Cream.

    If you don't like those froo froo 'liquers' but instead prefer real liquor, add 1 shot Southern Comfort Bourbon or Rum

  • My dad just got a new G4 with OSX on it. He wanted to network it with his Win2K box so I thought I'd just build Samba on it. After I figured out how to get root on it, I discovered the most basic UNIX tools were not there (e.g., Make, gcc, etc.). There was nothing on the disks that shipped with it, so I went to apple.com and what they put you through to download the GNU tools is unbelievably bad. I like OSX, but it seems to me if they want people to develop for it they would want to make it easy to get the tools to do it. I had to fill out form after form after form and at the end there was still no obvious link to download the GNU tools. It was late and maybe I was just tired, so if anyone knows an easy way to get these let me know.
    • It would be nice if the dev tools came with all copies of OS X, but they don't. If you ordered the 10.1 update from Apple (the $20 one), it came with the cd's, i think.

      Also, if your dad just wants to connect to a SMB share, that support is built into 10.1. Just type the url in the Connect To.. item in the Go menu.

      It is supposed to work well, but i have personally had troubles with it connecting to some networks.
    • um, wasn't there a grey CD in the box labeled "Developer Tools"?
    • ...if anyone knows an easy way to get these let me know.


      Try Fink [sourceforge.net], it's got, among a mass of other stuff, Make. OS X comes with a version of gcc installed called cc. Fink will probably get you all you want other than that. Here [forked.net] are some common compiling problems and solutions for OS X.

    • If you install OS X yourself from the CD, you get the option of installing the gnu tools.

      I imagine Apple just pre-installs without for most regular users' convenience.
  • The review is right. It's not layed out well, it's difficult to navigate. Worst of all, most (if not all) of the examples from the book are taken from Apple's web site. Save yourself some money and time and get the book by Aaron.

  • coco? (Score:1, Offtopic)

    by Heem ( 448667 )
    Ahh my first computer. The COCO. 16k of ram, cassette player for storing programs, 300 baud acoustic coupler. Ahh yes. Oh wait, COCOA - nevermind.
    • Don't forget the best 8-bit CPU every made, the 6809. I bought one of those things just so I could hack out some 6809 assembly code.

  • java (Score:4, Informative)

    by Fillup ( 121335 ) on Tuesday December 11, 2001 @12:04PM (#2687612) Homepage
    No it's not a "marketing thing." If you know anything about OO and Java programming, it's actually very easy to write a Swing program that uses the Aqua look and feel. And you can place Cocoa-access code in its own objects so that you can remove / change that code later.

    I find that it's actually very good for prototyping complex GUI apps. And the reason there isn't much information about it is that the Java API is simply a name-for-name bridge to the Objective C api. The objects (almost all of them) are provided in Java as bridges to the actual Obj C objects.

    They essentially did the Visual J++ thing but they did it __right__. Their classes are in addition to the Java 2 platform, not a sneaky replacement for it. I personally wish __more__ vendors would provide platform-level access in bridged Java classes.

  • Objective-C Tutorial and Reference (Score:5, Informative)

    by Equuleus42 ( 723 ) on Tuesday December 11, 2001 @12:06PM (#2687619) Homepage
    For those interested in learning Objective-C (assuming a working knowledge of C), look no further than [apple.com]
    this PDF.

  • "There is another..." (Score:3, Informative)

    by desslok ( 7863 ) on Tuesday December 11, 2001 @12:07PM (#2687627) Homepage
    ...and it's Mac OS X Developer's Guide [amazon.com] by Jesse Feiler. It's probably best described as "a developer's introduction." It is very broad, covering topics from the Mach kernel to the Interfact Builder. It's at least worth a look.

  • So... (Score:3, Interesting)

    by banky ( 9941 ) <gregg.neurobashing@com> on Tuesday December 11, 2001 @12:08PM (#2687633) Homepage Journal
    Java applications that only run on Windows are *bad*, and Cocoa-Java apps are... well, no one said they are good per se, but you'd think Sun would have to object on the same grounds. 'Cept that it is Apple.

    But you'd think it's Unix, too, so it potentially steals market share...
    • They won't object because it's not the same thing.

      Apple created an Objective-C/Java bridge to allow programmers to access Objective-C objects and classes from Java. An external, native library, accessed through JNI funkiness. A person not running Mac OS X just doesn't have the Cocoa library, do they cannot use apps that depend on it.

      MS fuddled with the spec, and the VM, making what could've been standard Java apps not run on other platforms and virtual machines.

      So Sun couldn't object on the same grounds- unless interfacing with any native library is grounds enough for you. And if it is, why not stop the people making GTK+ bindings for Java too?

    • Re:So... (Score:3, Insightful)

      by TWR ( 16835 )
      I can't tell if this is anti-Apple FUD, anti-Sun FUD, or anti-Java FUD.

      The fact is that Sun had no problems with MS making it easier to tie Java apps to Windows via J/Direct.

      What they objected to was MS leaving out bits of functionality by obeying the letter of the spec and not the spirit (RMI support, for example, required accessing an FTP server at MS that would change from time to time).

      Apple has been providing ways to bridge Mac OS calls and Java for about 4 years. Sun has never objected, because Apple also implements the Java spec to aching accuracy. They just add extra stuff on top of it.

      -jon

  • This page contains a list of applications that are either already Carbonized or Cocoaized or are in the process of being Carbonized or Cocoaized. Check it out at Xappeal [xappeal.org]

  • Be careful! (Score:3, Informative)

    by BoarderPhreak ( 234086 ) on Tuesday December 11, 2001 @12:09PM (#2687640)
    Neither this book, nor "Learning Carbon" are for beginners! There's not much in the way of introductory text in either.

    IMO, there's a MUCH better book on Carbon programming out now, which is about 1.75" thick and darned heavy - I think it's called "Carbon Programming" or vice versa... D'ohhh.

    Keep in mind, too - what the difference is between Cocoa and Carbon. The former being Objective C (object oriented and much like C++) and the "real deal" for MacOS X programming, and the latter being based on C. The benefit of the latter being that it will run on either MacOS 9 or X. Then again, there's higher level languages that you can use like RealBasic or Applescript - or hell, Perl. :)

    Be sure to check out Everything Mac [everythingmac.org] for loads of MacOS X goodness.

    • Yes, Objectiv-C is (truely) object oriented, but is very much unlike C++, which is "object oriented"-like. Well, you may disagree about those definitions, but they use objects differently, actually in an incompatible way. Carbon OTOH doesn't care if you use procedural languages like C or (Real)Basic, or an OOP wrapper with languages like C++. That's why, if you want to use C++, you have to use Carbon for programming - just like Alias|Wavefront did with Maya [aliaswavefront.com]

  • Python for Cocoa (Score:4, Interesting)

    by eAndroid ( 71215 ) on Tuesday December 11, 2001 @12:11PM (#2687656) Homepage
    There is work being done to let Python be another Cocoa language by enabling python to access Objective-C objects. This is a great idea as it would let Cocoa apps be built and prototyped very fast.

    Even if you don't favor making your releases in Python few people disagee that Python is great for rapid prototyping.

    If you are interested in helping out visit the sourceforge project [sourceforge.net] where work is just beginning on a rewrite to take advantage of Python 2.2's new class/type system.

  • Idiots keep attacking Objective C 's syntax (Score:5, Insightful)

    by lordpixel ( 22352 ) on Tuesday December 11, 2001 @12:14PM (#2687684) Homepage
    There are tons of posts here saying Objective C has an ugly syntax.

    What they mean is it doesn't look like C and C++ and Java.

    Of course, how it looks has no bearing on how useful a language it is (heh, think Perl ;), but these people are too ignorant or blinkered to realise this.

    Who cares what the syntax for calling a function is? So long as its not 3 pages of code its irrelevant.

    Do we see any insightful comparison of the truly powerful language features from these people? Do we see discussions of how C, C#, C++, Java and Obvjective-C's approach to types and bindings work? How they support dynamic behaviour?

    eg, I'm prepared to state that Objective-C makes generic types unnecessary, whereas C++ relies on them and Java is introducing them (slated for JDK 1.5). This is a good thing in C++, will be a good thing in Java, and I expect to see them in C# one day, because of commonality between how these languages are defined. Objective-C doesn't need them, it has another solution, more akin to Smalltalk.

    We don't see this sort of comment (shallow though my example is) from most of the posters here because frankly all that they're experienced enough to comment on _is_ the syntax.

    Even all that said - the features of the language pale into insignificance next to the quality of the class library. Java is nothing without the java.* and javax.* classes, C# is useless without the .NET runtime or at least the Base Class Libraries. C is limited without sdtlib, C++ needs the STL or on MS platforms (shudder) MFC to get the full benefits.

    This is a review of a book about Cocoa, not Objective-C. The class library, not the language. The class library will dominate any concern over the language used to program it. Learning a language takes days (or weeks if its something completely new to you like your first declarative functional or logical language). Learning a class library can take months or years (depending on the size).

    Do yourself a favour and learn some more languages. Learn about languages. Use real class libraries. Then open your big mouth!
    • The only complains I have about ObjC are the obscenely long method names, and the memory management.

      The infix notation for specifying method parameters is novel, since it allows for a message to read much like natural language. However, that tends to breed really long method names/parameters, which means the programmer is forced to type more. The collections libraries is evidence of that. I don't like typing that much. Its a minimal complaint, but it has dampened by initial enthusiasm for the language.

      As for the memory management, I hate manual reference counting. It's one of the most egegious aspects of COM on Windows, and I was quite disappointed to discover it is an issue in Objective C.

      I do still have much to learn about Cocoa and Objective C, but those two issues have been a source of frustration to me.
    • I think the complaint about Objective C is not that "[foo...]" is uglier than "foo(...)" but that it uses both styles in the same program. SmallTalk only used the square bracket syntax for all function calls.

      The problem is that the original Objective C was a C preprocessor that did not even parse things, it acted like a macro processor and replaced any "[...]" sequence preceeded by anthing other than a C identifier with a C function call taking string arguments.

      If they had worked harder to parse C some more I'm sure they would have used a syntax like "method(object,...)" so that you could easily switch function calls to method invocations.

      Or they could have used SmallTalk unchanged.

      But the actual compromise is not something anybody should be proud of!

  • How about Early Adopter Mac OS X Java? That covers Cocoa too, and is (to date) the only book that covers Java and Cocoa. The ISBN is 186100611X, and I am not at all biased because I was one of the editors on it :-)

    Read about it here [wrox.com]

  • Objective-C - Apple give away whole free book (Score:5, Informative)

    by lordpixel ( 22352 ) on Tuesday December 11, 2001 @12:20PM (#2687723) Homepage

    If you want to know more about objective c, or to prepare before reading the books above, or to gain more depth of understanding of the language if the chapter or so spent in the above books doesn't explain enough, then look no further than this:

    Object Oriented Programing and the Objective C language [apple.com]. Originally a Next Step book, now available free (HTML/PDF) at Apple.com or thru print on demand at Fatbrain.

  • There's a free ~40 page tutorial + sample code available at http://www.areax.net that covers both an introduction to Objective-C for C++ programmers as well as Objective-C++, the new (well, recently revived) language that lets you use C++ libraries in Cocoa. Check it out! link [areax.net]

  • GNUstep (Score:3, Interesting)

    by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday December 11, 2001 @12:36PM (#2687824) Homepage
    How much of this is applicable to GNUstep or NeXTStep? Any of it?

    • Re:GNUstep (Score:4, Informative)

      by sellout ( 4894 ) <greg@technomadic.org> on Tuesday December 11, 2001 @01:18PM (#2688074) Homepage
      As far as I've been able to suss out (I haven't had a chance to play on OS X yet, but I have looked at a bunch of the developer docs), Cocoa is pretty much a relabeling of the NeXTStep API. I imagine that any code you write for Cocoa will compile fairly easily under GNUStep. In fact, the GNUStep guys are working to add a Java API (in addition to the extant Obj-C API) to match the one that Apple added for OS X.

      • Ho Hum. (Score:2)

        by fm6 ( 162816 )
        The NeXTStep API has been around for quite a while, and has never really had a following. It's been sold as a basic API on the original NeXT Computer [vnunet.com]. When that failed, they tried to sell just the OS. When that failed, they tried to sell it as an API that would run under Unix. When that failed, they finally managed to sell the whole ball of wax to Apple after Copeland self-destructed. (A close relationship between the chairmen of the two companies helped.) I find it terribly interesting that:
        • there's so much breathless enthusiasm for an API that has repeatedly failed to catch on;
        • people actually think that Cocoa is going to seduce a significant numbers of Carbon, Windows, or Linux/Unix developers -- isn't it a little late in the game for that kind of realignment?
        • this discussion seems to be dominated by Objective C people; wasn't a big part of the development effort to make this OS accessible to other languages?
        • why this whole thing took so long -- this isn't a new OS, it's a port of an existing one!
      • Cocoa owes everything to the NeXTStep API. Without much relabling either. Everything is still derived from NSObject. :)

  • You see it coming, don't you? (Score:4, Troll)

    by still cynical ( 17020 ) on Tuesday December 11, 2001 @12:37PM (#2687832) Homepage
    First we had Java Beans, now Cocoa Puffs?
  • Here are some more books on MacOS X / Cocoa / Carbon Programming:

    Java: "MacOS X Java" Wiliams, Albert, Hart, Hopkins and Steinberg, Wrox press. (Just got this one, reading it now)

    WebObjects 5 for Java: A Developer's Guide (With CD-ROM)
    by Jesse Feiler (Paperback)

    Java & ObjC: "Mac OS X Programming" by Dan Parks Sydow (got this one on order)

    Mac OS X Developer's Guide by Jesse Feiler (Paperback) (this is an OK text, some good examples with ObjC & Java, but lacks a lot of detail on many Cocoa topics)

    Mac OS X Carbon Developers Black Book (With CD-ROM) by Dan Parks Sydow (Paperback) (don't have this one)

    REALbasic: "REALbasic: The Definitive Guide" by Matt Neuburg (good book, but only covers development with REALbasic .. and you can develop "X-only" applications with this)

  • What about Apple's other Cocoa? (Score:3, Interesting)

    by Blue Neon Head ( 45388 ) on Tuesday December 11, 2001 @01:29PM (#2688143)
    This is slightly offtopic, but Apple had another project called Cocoa which was supposed to be a visual programming language for kids to use. Anyone know about what happened to it?
    • I'm not entirely sure, but I was pretty involved in it up to a point. I think they stopped developing it, but I think it was done out of house, so those guys kept working on it. That's the last I heard of it, and I'm betting it's dead and buried now.

      It's pretty unfortunate too, it was a great way to write simple little apps. I wrote a whole Mendelian genetics breeding simulation (which I still have somewhere), and I have a couple of books that have pictures and descriptions from tons of little programs people wrote. It wasn't meant for serious work, but could make some nifty little demos very easily. Great way to get kids programming. I've thought repeatedly about doing a free version for linux, but it's a lot more work than I have time for. Still, it'd be a very worthy project.
    • Larry Tessler took it with him when he left Apple several years ago. There are some resources for "the other cocoa" still out there [google.com].

      'The other Cocoa' eventually [stanford.edu] found a new home and became known as Stagecast Creator [stagecast.com].

      -Mark

    • I think it was called HotSauce or HotCocoa or something like that.
  • Comment removed based on user account deletion

  • practical perspective (Score:2, Informative)

    by nikko ( 158280 )
    As a long time NeXTStep, OpenStep, Webobjects (yes, WebObjects also uses ObjC) programmer I'd like to point out a few things about ObjC and the NeXTish frameworks, without religious bias.

    ObjC was a very nice language when it first came out. For a hybrid language (object semantic hacked on top of ansi C), it is much more powerful and clean than c++, which is why I made the switch. However, it is absolutely erroneous to say that there are things you can do in ObjC that cannot be done in c++. You just have to jump through hoops of fire in c++ to achieve the dynamism of ObjC. On the other hand, it WAS a hybrid language: fundamentally still C. So it was no Smalltalk. Programmers are still fundamentally responsible for memory management (there's a refcounting scheme for helping) and this requires a high skill level. In large programs, tracking memory leaks could take time. Also, ObjC was not nearly as clean as Smalltalk in other respects. Some of the object semantics in ObjC were hacked on through the use of cpp macros. You could not stay entirely in the object world-- the facade of OO was not complete. In dealing with the low level of the runtime you would have to handle c structs.

    The state of the art moves on. But ObjC doesn't, for the most part. ObjC has some features that Java is lacking: method forwarding, posing, categories, etc. Still, there are no circumstances under which I would now choose ObjC over Java. Why? Advantages of Java over ObjC:

    - Automatic memory management.
    - No direct memory access. Because of this, I can feel comfortable working with junior programmers. Not the case under ObjC.
    - Only Objects and a few sensible primitives. No other data types.
    - Unicode based.
    - Strongly typed (yep, it's an advantage, good ObjC programmers type as much as possible anyhow)
    - Exception handling first class citizen of language (it's hacked on in ObjC)
    - Fully integrated threading model (much more difficult on ObjC)
    - multi-platform. I know java isn't perfect in this respect, but ObjC and the Foundation framework was much, much worse. Basic things like threading could work differently on Solaris vs. windows under OpenStep Foundation.
    - multi-vendor.
    - A tremendous number of third party tools.
    - A tremendous amount of third party information.

    I can go on and on. I really don't see the point of Apple pursuing Cocoa, except as far as they are locked into it for legacy reasons.

Slashdot Top Deals

FORTUNE'S FUN FACTS TO KNOW AND TELL: A giant panda bear is really a member of the racoon family.

Close