Linked by Jared White on Thu 24th Apr 2003 17:49 UTC
General Development There are two major varieties of Cocoa available. The first variety, possibly the more well known of the two, is the kind that you can use to make a nice warm cup of chocolate milk. While tasty, it's hardly proper subject matter for an operating systems information site. The second variety is far more on-topic: a programming environment for Apple Mac OS X that is the modern evolution of of the original NeXTSTEP frameworks. That's what I'm here to talk about today.
Permalink for comment
To read all comments associated with this story, please click here.
people grow to like the syntax
by mmalc crawford on Sat 26th Apr 2003 01:40 UTC

Over the last three years, I've taught Cocoa to I think between two and three hundred engineers. Most have had a C/C++ background. Initially, most view the square-bracket syntax as, at best, "odd". By the end of a week, most seem either to like it, or at worst give it (albeit occasionally grudging) respect. Long-term experience shows that the "named arguments" style leads to more-readable, more-easily maintanable code. To those for whom this is the first exposure to the syntax I'd say, "Try it for a while before you rant."

Regarding other aspects of the environment:

One could perhaps summarise Objective-C as being behaviour- rather than type-oriented. Those steeped in a long C++/Java tradition typically find the idea of not knowing what "type" an object is discomfiting. Experienced Objective-C developers are quite relaxed with the idea of just sending a message to an object, and expecting that the Right Thing will happen. The wide variety of Cocoa applications running reliably on users' desktops suggests that the Objective-C developers' attitude is justified...

As for memory management, this is another area which newcomers, and especially those who haven't written a line of code yet, think will be difficult. Typically the difficulties are of their own making. The strategy implemented in Cocoa is consistent, reliable, and simple. It's a shame Mr. White didn't see fit to link to the longest-running Cocoa-oriented website, since it includes a number of articles on the subject of memory management:

Those who persist in "not getting it" are, in my experience, typically those who are least willing to "let go" of their C++/Java experience and work with, rather than against, the system. Please note, this is an observation, not a value judgment. In a similar vein, I am sympathetic to those who would like the "freedom" that garbage collection offers, however I wonder how many of those who demand it have looked in detail at the full range of reference types in Java. And have considered the effect of a full garbage sweep in a video-editing application as the user is fine-tuning sound-track placement. Most developers quickly get used to the memory management system, and grow to appreciate the additional control that it gives them over their application's resource requirements.

Finally, regarding speed. There are two aspects to this:
(a) Recall that this is an environment that originally ran more than adequately on 68040-based systems with 16MB RAM (some might also say that the 68030-based systems ran fine with 8MB RAM, but I'll stay in easily-defensible territory). The overhead of a method lookup over a function call is minimal (I think it was estimated by someone once at around 10% -- note that there's a lot of caching). If that has a significant impact on your application's performance, I'd suggest that either it doesn't do very much, or it's badly architected.
(b) The slowest-running application is one that hasn't been deployed yet. 15 years on, Cocoa still seems to be the best RAD tool in existence. And better than just a RAD tool, you can take your first attempt and develop it into an industrial-strength application. This is in part due to the flexibility Objective-C offers...