Re: If GC is the solution, then what is the problem?
Le Chaud Lapin wrote:
Francis Glassborow wrote:
In article <1153169290.390188.20670@s13g2000cwa.googlegroups.com>, Le
Chaud Lapin <jaibuduvin@gmail.com> writes
It might be 5 years from now, but eventually, the pro-GC
people will realize that there is no susbtitute for good
form.
Or maybe the anti-GC people will realise that it has its
place. Both extremes are, IMHO, misguided. GC is not the
answer to all problems and in some domains it is pretty
nigh useless. OTOH it is in answer to some problems in
some problem domains and for those people its lack results
in them having to make considerable efforts to simulate
it.
Ah true...but let's not kid ourselves. If you pin a pro-GC
person to the wall and ask him why he wants GC, I suspect that
it would not be for the rare, esoteric designs that really do
beg for GC, but for the everyday, "i'll just new() this and be
done with it" code.
Could you support this with some concrete quotes which would
suggest it, or are you just throwing out gratuitous defamations
because you don't have any real arguments?
Before you start saying that the tool should not be banned for
lack of skill in the craftsman (which I entirely agree with) I
think it is instructive to ask...:)
"What percentage of real-world designs have an inherent need
for GC?"
About the same percentage of those which have an inherent need
for inheritance, or any other feature you can name. I can write
any application in assembler, so there is no "inherent need" for
anything more.
The question is rather what percent of real developments would
benefit from garbage collection. And while an exact numeric
answer is obviously impossible, everything indicates that a lot
would. Because garbage collection reduces the number of lines
of code you have to write and maintain, and thus reduces the
total cost of development. (Note that there is no miracle
involved here. This is true of any ready-made solution as
opposed to some custom development.)
This is the crux of what the non-GC people are saying (or at
least I am). We regard GC a crutch that encourages bad
design.
The problem is that all of the evidence is against you. Look at
the people in favor of garbage collection. Are you saying that
Andrei or I somehow don't favor good design, or don't know what
it is? For that matter, are you really saying that adding a
tool will turn good designers into bad ones? I don't even find
that plausible.
We believe that the ratio of designs where it really does
belong is so small that in those cases, it would be better to
implement GC as part of the resolution of the design and not
change the language itself.
Garbage collection has to be part of the language in order to be
robust. There are add in third party garbage collectors, but
all optimistically assume certain things concerning e.g. how the
compiler optimizer works.
And it obviously depends on your application domain as to how
likely garbage collection is to be an advantage. I can't
imagine an application on a modern Unix workstation, or a
Windows based PC, where it wouldn't be appropriate for some
things. Obviously, the situation will be different if you're
targetting embedded systems with very restricted RAM and very
tight, hard real-time requirements.
If the pro-GC people intend to use GC as a new model for
generic memory management, I think they should admit this
fact.
What fact? To date, you've only presented very arbitrary
opinions, which don't accord with actual experience.
Then, if that is the case, I ask that they show me the design
where they felt GC was necessary, and I will show a redesign
that is mostly, if not all, devoid of GC.
Sure. You are the expert in design, and know more about it than
all of the other people actually working in the field, and using
garbage collection.
You know very well that such a challenge is vacuous. Just
writing the requirement specifications of a serious project
involves man-weeks of effort, and you're not going to spend a
year on someone else's design just to prove your point. (And no
one in their right mind would ask you to, since in the end, it
really wouldn't prove anything.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]