[Apologies if this went off on the net prematurely... - I tried to kill
the earlier version].
In article <2330@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman)
writes:
|> >Steve Knight who writes applications for Hewlett Packard reckons that, for
|> >a given effort, he can write a POP-11 program for many applications that
|> >runs twice as fast as the equivalent C. Being able to use appropriate
|> >data-structures for the -problem-, knowing that he does not have to worry
|> >about reclaiming them, a particularly serious problem in an interactive
|> >program that may run ad infinitem, slowly clogging up its virtual memory
> >as
|> >it does.
|>
|> I have yet to be convinced that garbage collection is a requirement
|> for efficient programming. I have never found it difficult to decide
|> when I am done with an object and free() it. Perhaps if you could
|> describe a situation where automatic GC is a requirement, and not merely
|> a convenience it would help me to understand.
Are we getting into one of these "real programmers" arguments here. "Real
programmers don't use floating point - they write their fixed point routines
in assembly code and ought to know the range of the quantities they are
computing with". (Maybe they should...???)
But computing contains plenty of examples of things which programmers -knew-
they should throw away which turn out vastly to improve a product if they
don't. Compiler writers -knew- that all information about the names and types
of local variables was useless once they had generated object code. But this
information is -just- what is needed to provide a good debugging
-environment-. If the decision about what is or is not garbage is taken
automatically, then adaptation of a product to market requirements in which
what was previously garbage becomes gold is -much- easier.
And programmers do make mistakes, particularly in programs that have a
convoluted use of data, like compilers, algebraic manipulators and solid
modellers or indeed any application where there is a variety of different
-things- you can hang on trees. I notice that computer vision, now that it has
turned to C, is much less adventurous in the variety of entities it tries to
handle than in the old LISP/Pop-2 days.
Failing to return store leads to fragmentation and performance that
declines with time. Returning store that is -actually- in use leads to bizarre
bugs.
Of course there are other approaches. For example reference counting can be
implemented fairly painlessly in a language like C++ that allows user
definition of the (overloaded) assignment operation. But for my money
languages should provide such support automatically.
Robin Popplestone.
|