Since 2005 I have written several applications using Cocoa and Objective C. Last year I started to write a text editor using Cocoa, because in my job I had to deal with very specific programming languages for which there was no syntax highlighting. The editor features syntax highlighting, LatTex support, automatic substitutions etc. Having just moved to 10.5 at that time, I had the choice whether I wanted to adopt GC or use the old retain/release system. I decided to use GC for the new Cocoa project, although I knew that
a. the program would not run on older versions of Mac OS X
b. I might face some problems due to the GC framework still being buggy
c. I would lose direct control over memory management
As for a. and b., I think this is just a matter of time. Older versions of Mac OS X will simply disappear and the GC framework will be further enhanced.
As for c., I can understand that those who dislike GC fear that they lose control over the execution flow of their programs. It goes without saying that GC is not as efficient as allocating and freeing memory by hand. Still, for my part, I decided to hand memory management over to GC. Why? Because I believe that the goal of software development should be to write well designed and stable applications. Programmers spend a considerable amount of time trying to avoid memory leaks and dangling pointers. Even if you took great care while writing the code, you will find yourself skimming through the code from time to time checking all your release calls. Also, you will use debugging tools like ObjectAlloc to see whether you have overlooked something. This time is better spent improving the application's design and developing fast and stable algorithms. If an application performs poorly, this is more often than not due to slow algorithms. If the algorithm is bad, manual memory management won't make up for it. If you optimize your code according to Apple's Cocoa/Core Foundation guidelines as well as to general code optimization rules that help the compiler tweak your code, your application will perform well, even if GC is enabled.
Apple has done a great job enabling programmers to concentrate on the code that makes an application unique instead of having to do "monkey work". Interface Builder is a good example, as everyone knows who has ever worked with Java Swing or TKinter etc. GC is yet another way to boost programmers' productivity. This is what progress is all about. Remember the "law of diminishing returns" (cf. http://en.wikipedia.org/wiki/Diminishing_returns). For example, twice the effort/input does not necessarily yield results that are twice as good. If with effort 1 you reach up to 80%, you may only get 90% with effort 2, and only 95% with effort 3. If well written C code can be almost as good as hand-optimized assembly code, say up to 90%, why bother writing your programs in assembly language to squeeze out the last 10%? I think, this applies to GC vs. manual memory management as well.
I see no reason why new Cocoa apps should not be garbage collected, unless perhaps an application creates a myriad of objects and allocates loads of memory in a very short period of time. Yet, as far as I know, Apple's engineers are already working on a GC solution for these kinds of applications. Then again, sometimes allocating vast amounts of memory can also be a design fault.
While I still use manual memory management when I write small command line tools and the like, I prefer GC when working on bigger (Cocoa) projects, because it simply saves a lot of time and prevents my applications from crashing due to a silly oversight in the retain/release cycle. In the long run, GC is - for most applications - the way to go. In fact, I think GC in Objective-C was overdue.
Last but not least: Please note that if you want to develop Cocoa apps for the iPhone, you should stick to the old retain/release system as the iPhone does not (yet) feature GC.
by Christoph Wendler — Aug 13
a. the program would not run on older versions of Mac OS X
b. I might face some problems due to the GC framework still being buggy
c. I would lose direct control over memory management
As for a. and b., I think this is just a matter of time. Older versions of Mac OS X will simply disappear and the GC framework will be further enhanced.
As for c., I can understand that those who dislike GC fear that they lose control over the execution flow of their programs. It goes without saying that GC is not as efficient as allocating and freeing memory by hand. Still, for my part, I decided to hand memory management over to GC. Why? Because I believe that the goal of software development should be to write well designed and stable applications. Programmers spend a considerable amount of time trying to avoid memory leaks and dangling pointers. Even if you took great care while writing the code, you will find yourself skimming through the code from time to time checking all your release calls. Also, you will use debugging tools like ObjectAlloc to see whether you have overlooked something. This time is better spent improving the application's design and developing fast and stable algorithms. If an application performs poorly, this is more often than not due to slow algorithms. If the algorithm is bad, manual memory management won't make up for it. If you optimize your code according to Apple's Cocoa/Core Foundation guidelines as well as to general code optimization rules that help the compiler tweak your code, your application will perform well, even if GC is enabled.
Apple has done a great job enabling programmers to concentrate on the code that makes an application unique instead of having to do "monkey work". Interface Builder is a good example, as everyone knows who has ever worked with Java Swing or TKinter etc. GC is yet another way to boost programmers' productivity. This is what progress is all about. Remember the "law of diminishing returns" (cf. http://en.wikipedia.org/wiki/Diminishing_returns). For example, twice the effort/input does not necessarily yield results that are twice as good. If with effort 1 you reach up to 80%, you may only get 90% with effort 2, and only 95% with effort 3. If well written C code can be almost as good as hand-optimized assembly code, say up to 90%, why bother writing your programs in assembly language to squeeze out the last 10%? I think, this applies to GC vs. manual memory management as well.
I see no reason why new Cocoa apps should not be garbage collected, unless perhaps an application creates a myriad of objects and allocates loads of memory in a very short period of time. Yet, as far as I know, Apple's engineers are already working on a GC solution for these kinds of applications. Then again, sometimes allocating vast amounts of memory can also be a design fault.
While I still use manual memory management when I write small command line tools and the like, I prefer GC when working on bigger (Cocoa) projects, because it simply saves a lot of time and prevents my applications from crashing due to a silly oversight in the retain/release cycle. In the long run, GC is - for most applications - the way to go. In fact, I think GC in Objective-C was overdue.
Last but not least: Please note that if you want to develop Cocoa apps for the iPhone, you should stick to the old retain/release system as the iPhone does not (yet) feature GC.