🚀 go-pugleaf

|>From: hopper@ntmtv.UUCP (Ian Hopper)
|
|I have always felt that some form of Garbage Collection is
|needed in order to do a decent job on reusable "Collection"
|modules.  Since the current favorite language (C++) does
|not consistiently (or easily) support GC, we do not see
|good quality collection modules.

Quality in what sense? Program efficiency? Cognitive efficiency (i.e. how
readable it is)? Correctness? Reliability?




-- Scott
   scotth@boulder.colorado.edu

From article <175@ntmtv.UUCP>, by hopper@ntmtv.UUCP (Ian Hopper):
> I have always felt that some form of Garbage Collection is
> needed in order to do a decent job on reusable "Collection"
> modules.  

    Actually, garbage collection is unacceptable to certain
    users, real-time users in particular.  Therefore, if one
    is designing a component for the largest possible audience,
    that component must manage its own space.  Anything less is
    going to result in a component which is essentially useless 
    when real-time software systems are being constructed.

    As far as languages go, I don't make use of GC (for the reason
    outlined above), and therefore don't care whether a language
    has GC or not.  Considerations like whether or not *secure* ADTs
    can be constructed (are limited private types available?), whether
    they can be constructed to be safe and efficient in the presence of 
    multitasking, and so on, are much more important.

    If there *is* garbage collection, whether required by a language
    or provided as a compiler feature (e.g., in Ada, where GC is an
    option that compilers are free to provide if the market wants it),
    my primary concern is that I be able to turn the damn thing off.

    Fortunately, Ada provides the pragma CONTROLLED, allowing me to
    specify that a given type is not to be touched by any garbage
    collector such that the compilers are required to obey, so there
    is room for coexistence as far as GC is concerned.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

In article <6478@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
<From article <175@ntmtv.UUCP>, by hopper@ntmtv.UUCP (Ian Hopper):
<> I have always felt that some form of Garbage Collection is
<> needed in order to do a decent job on reusable "Collection"
<> modules.  
<
<    Actually, garbage collection is unacceptable to certain
<    users, real-time users in particular.

This is not true: there exists at least one real-time garbage collection
algorithm (don't have the reference right now, email if you want it).

John
gateley@m2.csc.ti.com

>From: hopper@ntmtv.UUCP (Ian Hopper)
>Newsgroups: comp.sw.components
>Subject: Re: Reasons for low reuse
>Date: 13 Sep 89 03:43:32 GMT
>
>I have always felt that some form of Garbage Collection is
>needed in order to do a decent job on reusable "Collection"
>modules.
[...]
>
>The classic approach would be to copy-in and copy-out the contents
>of such containers, but simply passing pointers to contents is
>often much faster.
>
>Do we focus our efforts on languages that have garbage collection,
>or are we forced to use the copy-in/copy-out approach?  Regrettably,
>the USING code is quite different in the various cases.

It seems to me that once you admit dynamic allocation into the language, one
must at least concede the \desirability/ of having GC.  The only question is
whether the cost of supporting GC is excessive.  There are two costs that I
see:
 1] A performance penalty due to GC time and tag manipulation.  Unless GC
    support is controlled by a compiler switch, some of this overhead is also
    present in programs that don't use GC.  GC can also cause unpredicable
    delays.
 2] At the language level, a certain discipline in pointer use is required
    so that the garbage collector can locate pointers and not be confused by
    random data that might be a pointer.  

Being a Lisp programmer, it is understandable that I don't find either of
these costs prohibitive.  The performance penalty isn't as much as people
suppose: a lot of progress has been made in GC algorithms in the past ten
years, and these algorithms have recently begun to see practical use in
languages such as Lisp, Smalltalk and ML.  Also, as you hinted at above,
there are often hidden efficiencies that can only be safely realized in
systems that support GC.  So far as the language style issue, this isn't a
big problem for high-level languages other than C.

I think that Lisp is a constructive proof of the reuse potential in systems
that support "generic types", GC and first-class functions (e.g. procedures
in records, etc.)  As many whining system managers will tell you, Lisp
systems are big.  That bigness is mainly because a Lisp image has lots of
code in it; Lisp programs tend to have big working sets because lots of
that code is used.  

Coming from a Lispy language perspective, the main challenge is not to make
the system smaller, but to make it bigger so that there is more stuff out
there that the programmer can use.  (Of course, we want to maintain similar
cost-effectiveness, rather than just bloating with junk.)

>PS: Writers of collection modules in GC-based environments should not
>forget to create dynamically-expanding versions of their collections. 
>Itis very annoying to have to estimate the size of collections in
>advance, things always blow up on large data sets.

Yep, this is often something that we have to flame new Lisp programmers for
when we are breaking them in.  Of course, if you use a linked-list
implementation of your data structures, this happens for free.

  Rob