Re: Garbage Collection - The Trash Begins To Pile Up
James Kanze wrote:
Le Chaud Lapin wrote:
You seem to forget that an important aspect of engineering is
cost (and time to delivery). Anything which reduces cost
without compromizing quality is good. Thus, garbage collection
is good, since it measurably reduces cost, and in addition has a
positive effect on quality as well.
It does? Funny. I have been saying the exact opposite.
Of course the mentality that led me toward garbage collection is
still present. I haven't stopped wanting to reduce cost and
improve quality just because I have garbage collection.
There are people who haven't stopped wanting to lose weight, or appear
younger, or have smarter children. There is perception, and there is
reality. Reality is that we both want the same thing. In my opinion,
one style of engineering leads to it more readily and more consistently
than the other.
Most of the systems I've worked on run 24 hours a day, 7 days a
week, for years. In many cases, there are conventional
penalties for down time (something around 5000 Euro per minute
is typical). In others, there is a contractual requirement of
no more than 3.5 sec. downtime per year. And in at least one
case (a locomotive brake system), every failure was
investigated, with possible charges of criminal negligence.
It's because I work on such systems that I'm such a fan of
garbage collection. Anything which increases the reliability of
my code (which garbage collection provably does, because it
increases typesafety) is good, and anything which solves one
problem means more time to analyse the other problems, and avoid
errors there.
and that GC, (like XML was for a
while), is the silver-bullet of the moment.
You are the only person I hear claiming that GC is a silver
bullet. All of the proponents I know are shouting just the
opposite, that is solves one (and only one) problem. Such
statements on your part give the impression that you don't have
any real arguments to present against garbage collection, so you
have to invent them.
What is that problem? Memory management? Every time I ask for a
concrete example where GC would be useful, someone mentions cycles.
Is that all?
You're kidding. The material cost of errors in the software I
write can be exceedingly high.
The material cost of the software itself is not. If I built, for
instance, a motor controller to control robots in the dessert, and the
controller failed, the robot might be damage, but all the controllers
would have to be replaced. In your case, there is no cost for the
software that has to be replaced, only the machines which it affects.
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.
You've got to be kidding. Let an error creep into an ABS brake
system, and you'll see have fast there will be a recall.
I mean during development. A while back my younger brother came to my
lab with his new CPU that he had bought for $700.00US. I told him,
"Ok, you have to be disciplined when u put...and before I knew it, he
had try to insert the chip without aligning it. I spent the next hour
with a pair of pliers realigning the pins, then checking for cracks
under a magnifying glass. If I had told him to build a program to put
blue boxes on the screen, and he made red instead, big deal.
The *development* material cost is zero. This is highly unusual in
other disciplines. Just ask any rocket developer.
Of course, brake systems are a bit special; at that level, you
don't use dynamic memory, period. But even with the other
programs I work on, a programming error can be expensive.
Expensive in a secondary way.
You make a software Product A.
Your Product A affects a hardware Product B.
Product B might be expensive, but Product A has no material value.
None of the human senses can sense it. It cannot be touched, smelled,
tasted, heard, or seen. But people pay much money for it.
In software an uninitialized variable in a program means lost
development time and a recompile.
In some hardware, an uninitialized variable in a circuit (floating
input) means lost development time, a fried board, $300 for the board,
and possibly a call to the proto fab for a new board.
The same is true for rockets, chemical samples, biological samples...
Note we are talking about the development of the product, not the
employment of that product. You simply do not have the same luxury in
other disciplines to get even the *development* part wrong.
I don't know where you get your impressions about what software
does, or how it is developped, but they certainly don't
correspond to what I see.
I am not surprised.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]