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

[kaz@ashi.footprints.net (Kaz Kylheku)]

In article <9l0o87$duo$1@nh.pace.co.uk>, Marin David Condic wrote:
>Never said you couldn't have errors escape a spell checker. Never said you
>couldn't have errors escape a language implementation that has error
>checking features. Never said you should implicitly trust that just because
>something got past such a compiler that it was free from errors. What I
>*did* say was that machine checking for routine errors would result in a
>reduction of errors.
>
>Maybe what I don't understand is why there seems to be such a resistance to
>the concept of automated error checking in a computer language when we
>routinely build in all sorts of automatic error checking into our software
>to prevent end-users from making stupid mistakes. A simple data entry
>program routinely edits the input applying various sanity checks and
>refusing to accept something known to be in error.

We do these things for convenience. By validating data at the system
boundaries, we then don't have to have error checks related to this data
at module boundaries within the system, which would be inconvenient and
error-prone. Robustness is provided most easily by filtering input close
to the points where it enters the software.

Similarly, run time checks for array overruns and such provide debugging
convenience, because an error is caught at an early point. (Though not
the earliest possible point, of course: such failures are the result
of faulty logic which led to the computation of the bad value).

I agree with you that run time checks do not suppress any useful form
of flexibility, but I don't think that it's Richard Heathfield's position
at all that useful flexibility is provided by weakening the run time
checks.  You are arguing against a position that I know he does not hold.

The position he does seem to hold is that run-time checks are training
wheels for weak programmers, or something along those lines.  To an
extent that is true.  I agree with the general idea that a solid engineer
should be able to design a correct program in the absence of a computer,
rather than rely on trial-and-error design at the computer, whereby
we just bang the program out, see if it violates some run-time-checks
and then fix them. But of course, reasonable proponents of checking do
not hold the position that development should be done this way. They
still strive to write programs that do not trigger any of these checks.
Real world programs are too complex, and worked on by too many people
of varying quality, to be designed and implemented correctly. So then
testing is relied upon, and run-time checks support that testing.

I hold the view that run time checks are bad for programmer education,
because novices will simply learn rely on them for trial-and-error
programming, whereby they don't understand why a program is wrong,
or how to design a correct one. They simply try things, and then react
to error messages.  The best teaching language would be one in which
an error is caught, but its source is not revealed. The programmer
is informed that the program failed, and the student must find the error
by reading and analyzing the program. Moreover, the student should be
able to produce a correct program on paper, and this skill should be
verified by examinations in which no computers are permitted.

I also believe that tools which allow errors to pass undiagnosed, and
even allow erroneous programs to compute the expected result, are equally
bad for education, because they entrench the view that any program is
correct if it causes the machine to produce an expected result. Hence the
abstract rules of a programming language fall by the wayside.  Many C
and C++ programmers continue to hold this view long after completing
their formal education, and even after years of experience.