Re: Garbage Collection - The Trash Begins To Pile Up
Steven E. Harris wrote:
It's not just Java's fault. C and C++ are the exception (no pun
intended) in this regard. I program regularly in Common Lisp as well,
and sometimes Scala or Ruby, and I can create, return, share, and hold
objects without worrying about whose responsibility it is free
them. The only time these details arise in Common Lisp is when dealing
with FFI-related resources (calling C libraries from Lisp).
My age is showing. Scheme is the only GC'ed language I have used, and
I was forced to learn that. FORTRAN, BASIC, Scheme, Pascal, various
assemblers, C/C++, ...
Those coming to C++ from elsewhere probably try to apply the ideas
they're comfortable with, and find that yes, allocating everything on
the heap does work, but it creates a whole other responsibility
they're not used to bearing. There just aren't many teaching resources
that praise, say, auto allocation over heap allocation; the latter is
usually handled as an advanced version of the former, and hence more
resources go toward helping one deal with the heap -- even when the
better advice would be to avoid it entirely. Of course, "When you need
it, you really need it."
I think what is happening here is something far more significant that
garbage collection. We are in the midst of a battle between what
constitutes good engineering and what does not. There is a trend, for
example, in elementary schools, to teach the kids that, it is not so
important to know the answer to 11x17, but to be able to discuss
cordially with the other students why you got the answer wrong, and in
that discussion, to be able to manage your relationships. Parents who
know that their kids will have no problems with math detest this new
philosophy. Parents who know that their kids struggle with math and
feel that their kids might have an advantage with relationship
management love it. They think, finally, my kid can be batter than
the class genius. Sigh.
The same is happening to programming. I do not believe for a second
that a person who does not exercise the discipline traditionally
required of an engineer will be able to build non-trivial systems of
good integrity. And I do believe that the vast majority of the
engineers who crave GC (in any language) fail to see that, even with
perfect GC, the *mentality* that lead them toward GC in the first place
is will still be present, and therefore, even in a perfectly GCed
system, I would *still* be interested in taking a look at their
concoction. I think it would have been hard for such engineers to
build reliable systems to start with, and that GC, (like XML was for a
while), is the silver-bullet of the moment.
To use an analogy, electrical engineers will note the strong parallel
between what is going on in the software industry and what happened in
the early days of EE. When Laplace transforms came to be regarded as a
tool for managing complex linear circuits, there was a class war (no
pun intended) that erupted . Some engineers thought transforms were
too complex and wanted to use trigonometric "phasors", as trigonometry
was "easy". Others regarded the transforms as "fundamental" and
resisted. In the end, the transforms, which require a higher
mathematical ability, won out, and today, no professor anywhere would
dare teach trigonometric phasors as a proper technique. What happened
to the pro-phasor engineers? They are not engineers anymore. The
power of the transform method for building large, correct, reliable,
robust, predictable,...all of the attributes you would want in a good
system...eventually muscled out the phasor mentality.
I am not sure that this is how things will play out in software
engineering. As mentioned, the material cost of a bad software is
zero. If a software engineer speculates about something, tries it and
is wrong, nothing burns. Nothing explodes. There is no recall from
distributing a defective product. Redistribution of a "corrected"
version is relatively painless. The barrier to entry is lower. Want
to do linear systems? Study college level calculus, complex analysis,
appreciation of eignenfunctions. Want make a scripted web page? Make
a trip to the local bookstore and sit tight for 21 days.
So the question is not really whether GC *can* be useful. Of course,
it can be useful. Goto's can be useful. The question is whether GC
will help those who already do not create well-engineered systems in
C++ do so (that is still a goal right?), and whether adding GC will be
a detriment to those who already create well-engineered systems in C++.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]