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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-13 02:27:18 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.uchicago.edu!newsswitch.lcs.mit.edu!nntp.flash.net!news.algonet.se!newsfeed1.telenordia.se!algonet!uab.ericsson.se!erix.ericsson.se!newstoo.ericsson.se!not-for-mail From: Ulf Wiger 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. Date: 13 Aug 2001 11:27:02 +0200 Organization: Ericsson Telecom AB Sender: etxuwig@avc303 Message-ID: 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> <6GUc7.40882$B37.845041@news1.rdc1.bc.home.com> NNTP-Posting-Host: avc303.etxb.ericsson.se X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Xref: archiver1.google.com comp.lang.ada:11836 comp.lang.c:73855 comp.lang.c++:82042 comp.lang.functional:7499 Date: 2001-08-13T11:27:02+02:00 List-Id: >>>>> "Kaz" == Kaz Kylheku writes: Kaz> The position he does seem to hold is that run-time checks are Kaz> training wheels for weak programmers, or something along those Kaz> lines. To an extent that is true. I agree with the general Kaz> idea that a solid engineer should be able to design a correct Kaz> program in the absence of a computer, rather than rely on Kaz> trial-and-error design at the computer, whereby we just bang Kaz> the program out, see if it violates some run-time-checks and Kaz> then fix them. This is a widely held opinion, which also has great appeal to management. Too often, I encounter glib claims that formal design is the way to go - that we should just do some more thinking before we attack the keyboards. Then we will finally be able to build systems that work. The thing that often gets lost is the realisation that experienced engineers of complex software systems will always do both, and understand that success lies in a careful mix of thinking, modeling and experimentation. Furthermore, some engineers are great at experimentation while others are better at static analysis and modeling; you do not often see both qualities well represented in the same person. Our approach is to program in Erlang, which is fun to program in, but still possesses most of the qualities of a high-level modeling language. It also has strong run-time type checking and support for building "self-healing" systems. Our products must function well even in the presence of errors (and we don't pretend that we can eliminate errors during the design phase.) Kaz> But of course, reasonable proponents of checking Kaz> do not hold the position that development should be done this Kaz> way. They still strive to write programs that do not trigger Kaz> any of these checks. Absolutely. We try to foster a zero-tolerance attitude towards run-time errors during design and testing. We also tell our programmers to write programs so that they either work as intended or crash. That way we can find the errors and fix them. Declarative symbolic languages are absolutely wonderful for this. Kaz> Real world programs are too complex, and Kaz> worked on by too many people of varying quality, to be designed Kaz> and implemented correctly. So then testing is relied upon, and Kaz> run-time checks support that testing. I often encounter problems which seem to defy analysis, but can still be solved through experimentation -- it will just be extremely painful until we stop running around in circles and try to build something and watch it crash. Only then do we begin to understand the problem. Having said that, it's not unusual in our environment to spend 6 months to a year analysing a problem before we start implementing. The trick is finding a balance. Kaz> I hold the view that run time checks are bad for programmer Kaz> education, because novices will simply learn rely on them for Kaz> trial-and-error programming, whereby they don't understand why Kaz> a program is wrong, or how to design a correct one. They simply Kaz> try things, and then react to error messages. The best Kaz> teaching language would be one in which an error is caught, but Kaz> its source is not revealed. He he, I'd just love to have a program written in such a language running in an unattended mission-critical embedded system. (: Perhaps the best teaching tools do not have to be useful outside the classroom? BTW, I think C and C++ programs have a tendency to behave exactly like that: they dump core, and if you're lucky, the core can actually be analysed. Otherwise, your only hope is to try to reproduce the situation with an instrumented system. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB