Re: How Ada could have prevented the Red Code distributed denial of service attack.

[cross@augusta.math.psu.edu (Dan Cross)]

In article <3b6e981c.1477345425@news.worldonline.nl>,
Richard Bos <info@hoekstra-uitgeverij.nl> wrote:
>> I see.  And have you ever worked on a project with more than one
>> programmer?
>
>Sure. And when I write a bug, it's still my bug. When one of us writes a
>bug but I don't know who did it yet, it's our bug. It's called
>"responsibility". And it's the programmer's responsibility, _not_ the
>tools'.

If the programmer is really taking responsibility for his or her
actions, why would he or she willingly choose to use a tool that s/he
was more likely to make a mistake with?  Wouldn't programmers with this
sense of responsibility be lining up to use tools that would enhance
the safety of their software?

...or is it that they're too macho to admit their fallability and instead
come up with lame excuses on the order of, ``I make sure to be aware of
what I'm doing when I program!''

Well, we all try to do the latter, but what seperates the good
programmers from the really great ones is that the latter recognize
their own limitations and react accordingly, including using tools that
are safer.

But no one ever said that, ``oh, the tool will take care of it.''  What
we did say was, ``the tool helps the programmer to take care of it.''
And that's the important distinction; tools can't solve problems for
us, but some tools are more effective than others at assisting us to
solve problems.

As has been stated before in this thread, none of us are 100% all the
time.  We make mistakes; we're human.  It's the wise programmer who
recognizes this and takes it into account by using tools he or she
knows will catch some of those mistakes.  She takes responsibility for
her actions and attempts to address her natural, humanistic
shortcomings by equiping herself with the best tools for the job.

>> Who ever said there was a language that would prevent one from making a
>> mistake?
>
>You patently do not understand the meaning of the word "sarcasm". You
>must be a USAlien.

You resport to ad hominem attacks when your logic breaks down.  You
must be an arrogant European.  :-)

>> Indeed, today's programmer's attitude towards quality and quality
>> assurance represents a sad truly state of affairs.  Case in point,
>> programmers who feel that their work is done in a bubble, and refuse to
>> use tools which are likely to reduce [*] instances of error injection.
>
>Such as? Let me remind you that array bounds checking only allows you to
>spot array bounds infringements _after_ they have happened. Only a
>thorough design can help prevent bugs to occur in the first place.

Such as, oh, I don't know, programming in Ada instead of C, making
their code legible enough to be reviewed by their peers, actually
thinking about what they're doing.  That sort of thing.

Of course, no one argues that good design (and before that,
requirements gathering and analysis) are requisite for reducing
defects. In particular, I've stated in this thread that it is
absolutely important.  But, it's not the only thing, and any tool that
helps us catch those other errors is a Good Thing.

btw- Array bounds checking isn't the only thing that Ada does to help
protect the programmer from his or herself.  I will note, however, that
it's a lot nicer to get an array bounds exception and handle it
accordingly than to simply have a program crash with a segmentation
violation or bus error; both common things in C.

	- Dan C.