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: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-03 08:05:28 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.ems.psu.edu!not-for-mail From: cross@augusta.math.psu.edu (Dan Cross) 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: 3 Aug 2001 11:05:25 -0400 Organization: Mememememememmeme Message-ID: <9keejl$fhj@augusta.math.psu.edu> References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> NNTP-Posting-Host: augusta.math.psu.edu X-Trace: boatanchor.ems.psu.edu 996851128 21895 146.186.132.2 (3 Aug 2001 15:05:28 GMT) X-Complaints-To: security@psu.edu NNTP-Posting-Date: 3 Aug 2001 15:05:28 GMT Xref: archiver1.google.com comp.lang.ada:11227 comp.lang.c:71907 comp.lang.c++:79668 comp.lang.functional:7258 Date: 2001-08-03T15:05:28+00:00 List-Id: In article <3b6a453c.1193942215@news.worldonline.nl>, Richard Bos wrote: >> Yes, but would the average car driver buy a car without seat belts now? >> Assuming the answer is, ``no...'' why would the average programmer choose >> to use a programming language with seat-belt like features? > >They couldn't, now, but more than a few simply refuse to use them. Indeed they don't; much the same way as many programmers don't make use of safer tools. Most of the time, it doesn't matter, but sometimes it *really* does. >But a more close analogy: how many people choose to drive only on 50Mph >roads, because it's safer? Bounds checking _does_ come at a price, you >know. Sure it comes at a price, but this is where the analogy breaks down; often bounds checking can be done in such a manner that it's almost impercetible in terms of the performance difference compared to non-bounds checked systems. Ie, a few percentage points difference. Maybe the difference is between going 70MPH and 63MPH or so. A personal anecdote about people driving too fast: I was skateboarding across 3rd avenue in Manhattan a couple of weeks ago, and a guy driving a car ran a red light and ran into me. Luckily, he had managed to slam on the breaks, and I had managed to swerve, so by the time he hit me, it was just a ``tap.'' However, I was pretty furious, and aquanted the driver of the car with that fact more than adequately. He said he had had to swerve to avoid rear-ending a car (I don't know if careening through a pedestrian walkway at an intersection is the best course of action to contemplate in avoiding a car-to-car accident, though!). Anyway, he was obviously pretty shaken up, and no harm was done, so we both went our seperate ways. However, I had started to think that here was a good example of someone who wasn't really paying attention to what they were doing (why should anyone be going fast enough that they have to swerve to avoid rear-ending a car at a light in New York City?), and were placing their own convenience ahead of the general safety, with possibly disasterous results. Luckily, I had managed to swerve, but had someone else been in my place who wasn't able to get out of the way before he mostly stopped (say I had been an elderly person), someone could have gotten seriously injured or killed. Is one's convenience, or some modicum of additional speed, really worth the risk? A parallel can be drawn to software. We often hear people saying, ``oh, I don't want to deal with bounds checking because it'll slow down my program.'' My answer to this is always, ``well, does that matter? Does your program need to be that fast? And how much will it really slow things down?'' Often, the answers are surprising mundane and support bounds checking. Wasn't it Henry Spencer who used to say, ``that tin god, efficiency'' ? >> Going back to programming, can we guess that as the number of programming >> related defects goes down, the number of design related defects rises? > >Since the design is part of the programming (or should be!), I can only >answer "Mu!". Huh? ``Design as you go'' is rarely a good strategy; you should always have some idea how to start before applying fingers to keyboard. Even methods such as `extreme programming' (which emphisizes step-wise refinement of both design and code) doesn't just start with ``int main(...)'' and go from there; you start out with a pretty good idea of what you want to accomplish and how you want to do it. - Dan C.