From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <808@quintus.UUCP>
Date: 5 Dec 88 05:47:49 GMT
References: <4125@enea.se> <3733@hubcap.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
List-Id: <comp.lang.ada>

In article <3733@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>   No, I do NOT want garbage collection.  Since GC cannot handle the
>   problems of circular-list garbage without outrageous time expenditures,

Are you up-to-date on this?  There has been a lot of work done on GC in
the last 5 years.

>   Furthermore, GC encourages sloppy programming.

How so?  Have you some data on this?  I very much prefer languages with
automatic storage management (Lisp, Pop, Prolog, Simula 67, SmallTalk, ...)
because there is a large class of mistakes you simply can't make (e.g.
referring to nonexistent storage) and the only real sacrifice in
expressiveness is that it is harder to write programs which crash when a
fixed-size buffer overflows (:-).  It would be a service if you could
elaborate on this:  if I knew what sort of sloppiness was encouraged I
could more effectively try to avoid it.