From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-10 10:16:50 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <9kpo9r$415@augusta.math.psu.edu> <5drpk9.l0e.ln@10.0.0.2> <9krhd2$6po@augusta.math.psu.edu> <9kubta$h4p$1@nh.pace.co.uk> <3B738145.CC94E732@eton.powernet.co.uk> <9l0o87$duo$1@nh.pace.co.uk> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: <6GUc7.40882$B37.845041@news1.rdc1.bc.home.com> Date: Fri, 10 Aug 2001 17:16:50 GMT NNTP-Posting-Host: 24.68.85.82 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 997463810 24.68.85.82 (Fri, 10 Aug 2001 10:16:50 PDT) NNTP-Posting-Date: Fri, 10 Aug 2001 10:16:50 PDT Xref: archiver1.google.com comp.lang.ada:11777 comp.lang.c:73438 comp.lang.c++:81612 comp.lang.functional:7472 Date: 2001-08-10T17:16:50+00:00 List-Id: 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.