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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 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-02 10:38:26 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" 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: Thu, 2 Aug 2001 13:29:58 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9kc2mo$rbb$1@nh.pace.co.uk> References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 996773400 28011 136.170.200.133 (2 Aug 2001 17:30:00 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 2 Aug 2001 17:30:00 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:11109 comp.lang.c:71694 comp.lang.c++:79397 comp.lang.functional:7204 Date: 2001-08-02T17:30:00+00:00 List-Id: If it is true that "The more possible programming related defects you need to consider, the more you think about your design" then it stands to reason that we all ought to go back to programming in machine code. After all, I can't think of a better way of increasing the number of possible programming defects than having to worry if the zero you just wrote should have been a one. Machine code programming ought to result in bullet-proof, perfect software design! :-) I'm not against someone bench-checking their code for errors - maybe re-reading it as you tidy up the format and re-thinking your assumptions - or even just leaning back and thinking about the design and wondering if there is a better way. I do that all the time. (Of course there comes a time when you need to shoot the programmers and move along into production.) But I just don't think it is reasonable to believe that adding automated checks for errors can be anything *but* a good thing. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Dan Cross" wrote in message news:9kbvsr$a02@augusta.math.psu.edu... > In article , > Daniel Fischer wrote: > >> Or is it that we're no longer hiding those design related defects behind > >> our programming errors? > > > >Don't think so. The more possible programming related defects you need to > >consider, the more you think about your design. > > Hmm. But as the minutia that we have to deal with goes away as > programming becomes more abstract, we are freed to concentrate more on > the design. I'd have thought that worrying about the programming > related defects took up so much time there was little left to worry > about the design. Though on the other hand, one can see that if > something is really hard to implement, folks will think really hard > about how to make it easier (and hence less error prone). > > Maybe the problem is that as our ability to deal with complexity goes > up, we feel compelled to build more complex systems ``because we > can.'' In other words, it's a two edged sword. > > - Dan C. >