I wrote before about how I learned programming the Mac using a scripting language, using its native API call plug-in scheme and how that made me realize that using scripting languages and their bridges to other languages or the native APIs (or even AppKit) is a great way for people to learn programming at their own pace.

Today, someone on an Apple mailing list complained that Garbage collection was

replacing one problem with two problems, one of which is the precise shape of the original problem

because the unpredictability of when garbage is actually collected means you are still forced to manually manage scarce resources instead of letting the object's destructor take care of it.

That's a very one-sided view: The advantage of Garbage Collection is not that it solves the problem, but that it partially automates the common case. If you don't have to write a piece of code, you are less likely to forget writing it. And you are less likely to make silly mistakes (e.g. copying a release line, forgetting to adjust it, and then leaking one object and releasing the other twice).

In most of the cases, you don't care when a particular object is actually released, as long as you can reclaim the memory it uses up when you need it. The cases where an object actually equates to a resource other than memory are a fraction of the overall number of objects you use: The property list types alone get created and disposed of so often that a mistake in there can easily introduce subtle bugs much harder to track down than realizing your hold on a device or file or other scarce resource hasn't been relinquished.

People have programmed this way for ages. As above-linked article mentions, people would use AppleScript Studio because they are familiar with AppleScript, and can now, at their own pace, add new knowledge. They can add one small problem at a time, and learn to use AppKit and Foundation gradually, without having to familiarize themselves with the entire gargantuan complex system at once.

If you take one step back, you may as well ask the same question, once removed: Why do we use high-level languages that produce such inefficient code? Because most people don't want to debug their push/pop stack management code and make sure the alignment is right before each call if the language can take care of this for most of their uses. And for the few cases where they need it, they can use inline assembler.

Both are the same problem and the same solution, merely at another level. Language bridges, garbage collection and other conveniences are not here to completely save you from having to learn the details of the computer's workings. They are here so you can learn them later, out of order, and in smaller chunks. And they are also here to make life easier for those people that already know.