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 Richardwrites: >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