Re: Student views on Ada

[merlin@annwfn.com (Fred McCall)]

In <35kapa$1fqc@watnews1.watson.ibm.com> ncohen@watson.ibm.com Norman H. Cohen rambles
off talking to to nobody knows who:

>In article <85B31AAE640@annwfn.com>, merlin@annwfn.com (Fred McCall) writes: 
>
>|>                                                            if the
>|> language bashing comment is indeed the true state of affairs, it would
>|> appear to me that learning Ada first may have taught this individual
>|> some 'bad habits' that have led him to rely on the compiler to check
>|> things for him tht he should be aware of himself.  I've seen this happen
>|> frequently when Pascal programmers are first learning C.
>
>This line of reasoning leads to the conclusion that one should never use
>a spelling checker, or that pilots should not be warned of an approaching
>mountainside.  A writer should be aware of correct spelling himself and a
>pilot should be aware of approaching mountainsides himself.

No, but it does seem to lead to the conclusion that one should not be
taught to fly automatic aircraft and then expect to be able to fly the
other kind.  In fact, one would rather hope that even if taught to fly
on such an automatic aircraft that a pilot would be told what was going
on.  This apparently did not happen in this particular case (and does
not happen in general, if my experience with people is any indicator).

>
>Being aware that something is wrong when it is called to one's attention
>is one thing; noticing an error--perhaps a clerical error, perhaps an
>invalid but seductive line of subtle reasoning--when it's buried in a
>large and complex program is something else.

But knowing how to operate your tools is yet a third thing.  I assume
you have a point?

>
>Some C programmers, lacking a language that facilitates strong
>consistency checks, may argue that such checks are for sissies--that Real
>Programmers do not need them.  

These are no doubt the same C programmers who developed tools like LINT,
which they no doubt came up with because they felt they didn't need it?
Oh, one can find high school students who will argue for all sorts of
silly positions, but so what?

>However, a compiler that performs strong
>consistency checks is, like a spelling checker, an important tool for
>protecting us from our imperfections.  Its use should be a part of the
>state of the practice for responsible programmers, just as the use of a
>safety belt is part of the state of the practice for window washers.  To
>call it a bad habit is to deny that humans make errors.

Why is it that Ada advocates always have to come up with these silly
strawman arguments?  It's a bad habit to RELY on that protection (and
therefore not watch what the hell you are doing in the first place).
There's a real difference between that and the words you seem to want to
shove into my mouth.  If you really don't understand that difference,
then you are part of the problem you are expounding on.

Studies indicate that many times including 'safety features' doesn't
lead to any decrease in accidents; it just leads to people relying on
those safety features and then managing to get themselves killed when
they fail.  In other words, people wind up writing bad code *because*
they expect the compiler to protect them.  You should write good code
whether the compiler is there to protect you or not; then when you *do*
make a mistake you get some added protection from the tools.  Relying on
the tools and therefore not bothering to think about things in the first
place leads to people who can only write code if they have all that
safety checking -- in other words, people who don't know what they're
doing and routinely write bad code, then pounding on it until they can
get the tool to accept it.  

I'd rather have people who know what they're doing, thanks.

>
>Fools who make NO effort to desk-check their weekly reports to their
>managers or the logic of their programs, in the belief that their
>spelling checkers and compilers do it all for them, are bound to pay the
>price for their laziness one day.  But that's no argument for
>discrediting the reliance on tools that make manual error-checking more
>efficient and more effective.

RELIANCE on tools *should* be discredited, if it has any credit coming
in the first place.  Fools who think that relying on tools instead of
knowing what they are doing in the first place are bound to pay the
price for their ignorance one day.  Nothing is foolproof, because fools
are so ingenious.  And so it is with reliance on tools.  People can come
up with ways to do unsafe things in safe environements because they are
a lot more inventive about it than the folks who are continually trying
to surround them with enough foam so that they don't hurt themselves.

Tools are wonderful things.  Trust yourself, not the tools.  Otherwise
you are going to eventually leave a smoking hole in the ground where the
tool failed because you wrote something unsafe and expected the tool to
catch it.



--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.