Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!hsi!wright
From: wright@hsi.UUCP (Gary Wright)
Newsgroups: comp.sw.components
Subject: Re:  Re: Garbage Collection & ADTs
Message-ID: <599@hsi86.hsi.UUCP>
Date: 25 Sep 89 15:14:32 GMT
References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu> <909@scaup.cl.cam.ac.uk> <62342@tut.cis.ohio-state.edu>
Reply-To: wright@hsi.com (Gary Wright)
Organization: Health Systems Intl., New Haven, CT.
Lines: 68

In article <62342@tut.cis.ohio-state.edu> Golden Richard  writes:
>In article <909@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>[pro-GC arguments deleted]
>
>I find the current GC wars rather interesting, but I find myself siding
>naturally with Bill simply because I have *never* encountered a situation
>that absolutely demanded GC.   Even without automatic scope-exit destructors
>for ADTs, programmer-controlled storage management isn't difficult.
>I'd be most interested in seeing some concrete example where GC was the 
>'only way to go'.

Well, I have *never* encountered a situation that absolutely demanded using
a high level language.   That is why I still do all my programming in
assembly. :-)

If our criteria for deciding whether GC is better than explicit memory
management is based on absolutes, we will never come to a conclusion.

Explicit memory management is theoretically speaking equivelent to GC
(we are all using Turing machines aren't we?).  What we need to
determine is if a language that supports GC allows programs to be
expressed in a form that is "better" than a language without GC.
Clearly, it will be hard to come to a conclusion about which form of
expression is "better" than another.  We also need to determine if the
benefits derived from the ease of expression outweigh any performace
degradation.

This trade off has been made in the past.  A hand-coded assembly program
can probably be made to be more efficient in time and space than a program
generated by a high-level language compiler.  Yet most programmers 
don't use assembly.   Perhaps this analogy holds for the current debate
regarding GC.

It is interesting to note the advances that have been made in 
optimizing compilers.  Perhaps a sufficiently smart compiler for a language
that supports GC can figure out when GC can be avoided?  That is to say,
the compiler can notice when the last reference to an object will be lost 
and can explicity "dispose" of the object.  In general, the compiler won't
be able to determine this (thus GC) but for the simple cases, why not?

I have seen a number of people claim that GC can not be used in a
real-time system and then conclude that GC is a bad thing that should
not be used.  If this isn't a non sequitur I don't know what is.  There
will always be special cases that will require special techniques.
What I am interested in are language features that make my life easier
for the majority of applications that don't fall under the catagory of
"special case".  I also would like compilers that can do the dirty,
tedious work of deciding when to use special techniques instead of a
more general one.  Areas in which I see this now or in the future are:

	register usage
	parameter passing techniques
	dynamic vs. static binding (in the contect of OOP)
	function inlining
	GC vs non-GC

I am sure others can come up with more examples.

My predicition is that more an more people will start using languages
with GC but there will always remain those who think it is a "bad thing",
and there will always be situations in which GC should not be used.

There are people today who claim that we don't need anything more than
assemblers, and there are situations today in which it is the only 
reasonable solution.
-- 
Gary Wright 					...!uunet!hsi!wright
Health Systems International                    wright@hsi.com