Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!newsfeed.pitt.edu!uunet!mole-end!mat
From: mat@mole-end.matawan.nj.us
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
Message-ID: <1995Jan5.103233.26768@mole-end.matawan.nj.us>
Organization: :
References: <D16Ho3.4BE@lcpd2.SanDiegoCA.NCR.COM> <3e2bj6$43a@network.ucsd.edu> <1995Jan1.095619.367@isis.muc.de>
Date: Thu, 5 Jan 1995 10:32:33 GMT
Lines: 34
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:106112 comp.lang.lisp:16291

In article <1995Jan1.095619.367@isis.muc.de>, Mike.Chapman@muc.de (Mike Chapman) writes:
> David Hanley (dhanley@picasso) wrote:

> :         Did it ever occur to you that GC was not instilled into the
> : C++ language for a reason?  That there are many good reasons for
> : preferring manual memory management?
> 
> The point is that many of us find the reasons Bjarne gave 
> for not incorporating GC into the language to be invalid. 
> 
> The are very rare occasions and very *few* reasons for preferring 
> manual memory management. ...
 
> Using reference counting is just about the dumbest way of
> performing any kind of automatic GC there is.
> It has the worst performance of all, and simply does not
> work for most interesting practical data structures.

If you must reference-count every memory object, you're correct.  But
most data structures and most _representations_ allow you to know when
something is still needed and when it is not.

LISP, in particular, uses a representation throughout which makes this
impractical.

Not all languages do this.  Not all design decisions must lead to such
representations.

Some of us find this a better approach.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)
