Slashdot Mirror
Cocoa Programming for Mac OS X
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.
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 :)
For anyone interested in developing for Apple's platform, the Apple Developer Connection 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). 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.
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
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.
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...
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
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
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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 where work is just beginning on a rewrite to take advantage of Python 2.2's new class/type system.
I can't spell or type, but that doesn't mean I'm unusually stupid.
I suppose that "private:" is an obvious extrapolation of "case:" as well. Objective C++ doesn't extend the language as much as C++.
One of the big problems with writing GUIs in C++ is that the type system gets in the way. The kludges neccessary to support a GUI system on C++ are infamous. Most systems resort to macros. GTK-- uses templates. QT uses a preprocessor and language extensions.
Objective-C adds very little actual syntax to C, whereas C++ adds a whole bunch. C++ is the kludge to end all kludges, Objective-C does is far better. Have you ever done a project in Objective-C, or are you just another slashkiddie talking out his ass?
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
How much of this is applicable to GNUstep or NeXTStep? Any of it?
-- Ed Avis ed@membled.com
What feature of Objective C makes templates unnecessary? I guess you might be referring to the fact that I can send a message (i.e. call a method) on an object without having to guess at the type of the object (with lots of instanceof ugliness like I would need in Java).
I guess that's great for getting rid of the slightly inconvenient cast that I would need in (pre-generic) Java, but it doesn't give me any of the type safety of templates or generic types, because that's not going to stop me from adding an object of the wrong type to a vector, for example.
But I'm not very familiar with Objective-C, so maybe you have something in mind that would give me that kind of safety?
Objective C is kinda interesting, but the fact that it's a superset of straight C works both for and against them. It's somewhere in between C++ and Java in terms of cleanliness of the langauge (C++ being horrible, Java being decent), and if I didn't care about performance, I'd prefer Java or some other not-C compatible language. over Objective C.
When I got mac OS 10.1, one of the docs said something about Objective C++, which sounds scary as hell...
You're definitely right about class libraries being way harder to learn than langauges. That's why I think we need to shift some of the burden from class libraries to languages--i.e. use languages with more advanced features, even if they require more study to understand, that could make libraries and other large bodies of code easier to understand You only have to learn the programming language once, but every time you switch to a new project you've got to learn a whole lot of new libraries. More expressive type systems would really help here...
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?
Very good post, with very good points, but also, I think, wrong conclusions.
I'm an experienced java programmer and also a long time Cocoa/Objective-C programmer, Smalltalk expert and C++ programmer. I confirm that Java (and for that matter Smalltalk) has some very neat features that Objective-C lacks, the biggest and most useful one being real Garbage Collecting. This one thing alone would makes Objective-C development at least two time faster and improve a lot applications stability.
But Java has big limitations in many circumstances. Basically, Java is the Cobol of today. It is great for a vast range of enterprise application, but it is not a good platform to program games or word processors or spreadsheet or image processing programs, or industrial systems etc. In many areas like these ones, Objective-C is much better suited.
In addition, Objective-C is much more suited for developing on Mac OS X than Java for a very important reason that will probably never change: OSX is a UNIX system. And the native programming language on UNIX is C. It has always been that way and will probably not change. UNIX is itself developed with C. All the libraries, techniques etc. are C-oriented. No one can change this. It's a fact of life. And Objective-C is superbly integrated with C, since it *is* C plus an object model. This makes Objective-C a very good language for Mac OS X (or for any UNIX). Much better than Java, at least for many kind of applications.
I would really appreciate to have the opinion of the original poster (again, I really appreciated the post) on these arguments.
Uhm ... check your facts.
... but that's another story.
The NeXTstep API was never sold as a basic API. It came with the NeXT systems. It was part of the overall environment. Rip it out and you had an expensive Unix console with no windowing system. Not very pretty.
When that "failed", they just sold the OS. This is true, but it didn't fail so much as the hardware end not being too profitable (too much R&D for a small company). Oh, and the NeXTstep API was still included in that OS. Imagine that.
They've never tried to sell it as "an API that would run under Unix." Actually, it runs under Windows, too (when you buy WebObjects for Windows).
Also, just because something doesn't catch on, doesn't mean it is piss-poor quality. Beta kicked VHS's butt
I don't know if a significant number of developers will jump onto Cocoa, but Cocoa doesn't need as many developers. That's not marketing hype -- I've used more OSes/languages than I care to mention and they don't touch the level of engineering as has gone into Cocoa.
MacOS X is open to all sorts of languages, but that's more due to the Unix kernel than anything else (because lots of things run under Unix). NeXTstep had a Unix kernel from the early days (that would be the 1980's), so I don't see how you can claim OS X was specifically developed to make other languages accessible.
It took so long because they had to make it backward compatible with 20+ million existing Macintosh users. While upgrading the UI. And the kernel. And the APIs. And adding more standards support (XML, Java, etc.). The OS wasn't the long straw in the port.
/dev/mrg