Objective-C Garbage Collection: Take 2Based on the comments on both the original post here on Objective-C garbage collection and on John Siracusa's post, it looks like this is a hot button issue for some people. The biggest single issue is the perception that garbage collection means slow apps.
To me, this seems like a moot point in the grand scheme of things. At minimum, it's useless to worry about how fast or slow something is until we have it in our hands. Garbage collection isn't a new concept, and is rapidly becoming more the rule than the exception. We also know that computers are only going to get faster.
Combined with the basic need for easier programming and more stable software, this means that most Cocoa apps are going to be using garbage collection at some point. The only real question is whether it will be sooner or later.
There was a time that Quartz was called too slow to be practical, but it's just one instance of the rule that higher-level, more abstracted, more capable environments and APIs always win out in the long run. There's ample history to show what happens the developer of an OS or desktop environment gets tunnel vision and always turns down progressive APIs in the name of raw performance. Eventually, the platform ends up looking very dated.
Early on in the life of Mac OS X, some Mac developers even called Cocoa too slow for many types of applications. Those statements sound positively insane in today's environment. Cocoa has completely taken over the Mac development landscape.
All of this would probably also hold more weight if we hadn't heard this argument over and over again since the dawn of the microchip. C had no future because it was too slow compared to assembly. The same was said about C++ versus C, and the same about Java versus C++, scripting languages versus C/C++, and so on. Yet here we are.
The "Work is Good For You" Argument
Whilst reading through the FatBits comments, one really stood out at me. This one is by Rosyna:
As I've said before, this has no bearing on the quality of the OS itself but can make the quality of the applications much worse as cocoa does more and more for the developer. Case in point, when bindings came around and did almost everything for cocoa devs, cocoa devs thought it was great. But as soon as you start having a larger application that calls bindings many times a second, the performance starts to seriously degrade.
As Cocoa's barrier to entry decreases, so does the amount of knowledge required to use it which results in more applications of a lesser quality.
So many things. I really don't think garbage collection will make the quality of most applications worse. Few things are worse than an application continually crashing or leaking.
As for the second issue, not only is untrue that bindings does "almost everything" for the developer, but bindings can actually be faster than custom data population routines. Apple wants people to use this stuff, so they made sure it was very fast. For the most part, bindings is really just a standardized way to keep data synced between views and the model.
While simplified programming does mean less experienced programmers are more likely to publish software, it's not a point that's worth obsessing on. The potential benefits greatly outweigh the downsides. More people writing software for the Mac is overall a good thing.
More importantly, there are plenty of smart people with good ideas that can do memory management, but simply would prefer not to. There's no reason they should be artificially blocked from putting together great apps.
Bottom line: I can't see that garbage collection is going to be required -- at least not for quite a while. If you have good reasons to manage memory yourself, or simply like doing it, more power to you.
Objective-C Garbage Collection: Take 2
Posted May 10, 2006 — 20 comments below
Posted May 10, 2006 — 20 comments below