[gclist] Re: gclist-digest V1 #87

[William D Clinger]

Tom Lord made some good points, but his conclusion that garbage
collection is far from a panacea was a little too pessimistic.

For example, it seems to me that the compilers I have used and
written tend to be considerably buggier than the garbage collectors
I have used and written.  Paraphrasing Tom Lord, I could say

    If compilers never changed or needed to be extended and
    were known to be free of errors and completely reliable,
    then we could claim that compilers were a general method
    for translating high-level languages into correct machine
    code, but in fact compilers do need to be changed and
    extended and are prone to bugs.

This would not be a very good argument against using compilers,
and it doesn't change the fact that using a compiler is the only
sane way to construct most software.  Compilers may not be an
automated panacea that magically yields "error-free" generation
of machine code, but they come pretty close, and many of their
bugs arise from market pressure to emphasize efficiency over
correctness.

Like compilers, garbage collectors are hard to write, to debug,
to port, and to extend.  Once upon a time I was responsible for
a garbage collector that was used by thousands of programmers.
It made a lot more sense for me to spend the time it took to get
it right on a new processor or system than for those thousands
of programmers to port their manual memory management code for
thousands of programs.

Yes, the consequences of a buggy garbage collector are essentially
the same as the consequences of buggy manual storage management.
The difference is that porting and debugging a simple but adequate
garbage collector takes only a few person-months.  Debugging
thousands of manual storage management codes would take many
person-centuries.

Will Clinger