Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!uhog.mit.edu!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Re: Reference Counting (was Searching Method for Incremental Garbage Collection)
Message-ID: <CzxAv9.HF@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <CzpJ7I.44D@world.std.com> <3b5rjj$kg8@scipio.cyberstore.ca> <hbakerCzuoKv.E7J@netcom.com>
Date: Sun, 27 Nov 1994 11:06:43 GMT
Lines: 94
Xref: glinda.oz.cs.cmu.edu comp.lang.c:118323 comp.lang.c++:100825 comp.lang.lisp:15851

I'm going to but in again, although I'm aware my opinions are less
well informed than those of others in this thread.

In article <hbakerCzuoKv.E7J@netcom.com>,
Henry G. Baker <hbaker@netcom.com> wrote:
>In article <3b5rjj$kg8@scipio.cyberstore.ca> kevinw@whistler.com (Kevin Warne) writes:
>>In article <CzpJ7I.44D@world.std.com>, tob@world.std.com (Tom O Breton) says:

(But I've deleted a lot and the first comment here is Henry's)

>Therefore, the programmer will have to go to some explicit effort --
>even in Lisp -- to reclaim certain structures, whether or not they
>have cycles.
>
>>>1:      It's slow, due to count update overhead.
>><more stuff about programming techniques snipped>
>>
>>Of course, if you pare down the references to the minimum needed
>>and inc/dec as necessary, you'll have a fairly efficient system.  
>>Unfortunately it won't be automatic.
>
>I'm not sure what you mean by 'automatic' in this context.  If you
>mean 'oblivious to the programmer's coding style', then I suppose that
>you are right.  But what system programmer is ready to give up his
>right to explicitly manage certain resources in certain situations?

Look, we live in a world in which, 

(i) according to all the trade comics, there is a huge backlog of
code waiting to be written (although this may be because you get more
kudos for specifying than for coding...);

(ii) the average C (or similar language) programmer spends more time
debugging than coding (*);

(iii) the overwhelming majority of bugs in C (or similar language)
programs are problems with memory allocation (walking off the end of
the world; early deallocation; leaks) (*);

(iv) silicon is cheap and rapidly getting cheaper;

(v) programmers are expensive and steadily getting more so.

((*) Asterisks indicate bald assertions: I can't cite anything to back
these up, but it's my experience).

Yes, I too have worked on a machine with 4K words of store, and which
cost as much as a street of decent homes. Yes, in those days it was
vital that your code was as tight and efficient as possible. But in
these days of megabytes of core, hand crafting (for example) memory
management is at best an almost masturbatory vanity, and at worst a
gross waste of resources (since the time you waste getting the bloody
thing to work is far more valuable than the totality of the processor
time it will ever save).

Note that this argument doesn't apply if you are working on the next
version of MS Word, for example: but are you *really*? In any case,
one logic problem which escapes the debugging process is likely to
cause far more cost to far more users! I recently saw an application
for European Community grant which was 30% out because of a bug in MS
Excel, which had been trusted by the applicant and consequently not
double checked...

Using automatic store management of whatever kind removes the single
major cause of error in code, and allows the programmer to concentrate
on the logic of the program. It thus greatly speeds application
development, and enhances application reliability.

There is a place, of course, for low level languages like C: device
drivers and operating system kernels are obvious examples. These
things will be used by millions of users and will be required to run
for long periods perfectly reliably. Such programs are rare,
thankfully, because producing code of this quality is hard and far
fewer people can do it than think they can.

Building code is an engineering problem. Suppose you are building a
vehicle for a speed record attempt, you might very well argue 'right,
we'll weld this assembly by hand, because the very best craftsmen can
work to closer tolerances than a robot can, and this assembly is
critical'. However, if you were production engineering the next Ford
Mondeo, and you suggested hand welding the body shell, you'd be out of
a job.

If an automatic process can do a job more *reliably* than the
average human (and automatic store management can), and can do it
more *cheaply* than the average human (and automatic store management
can) then not using it is just amateurism.


-- 
--------simon@rheged.dircon.co.uk

	to err is human, to lisp divine
				 ;; attributed to Kim Philby, oddly enough.
