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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Tests in a software release Date: Wed, 15 Nov 2017 16:17:32 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Wed, 15 Nov 2017 22:17:33 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="16801"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: feeder.eternal-september.org comp.lang.ada:48917 Date: 2017-11-15T16:17:32-06:00 List-Id: "G. B." wrote in message news:ouhv6m$cig$1@dont-email.me... > Randy Brukardt wrote: >> "G.B." wrote in message >> news:oth5k4$eih$1@dont-email.me... >> ... >>>> Checks can be removed only when statically proven not to fail. >>> >>> Programmers may remove checks whenever they think >>> they should. No fancy proof is required(*). >> >> Such programmers should be fired at the earliest opportunity. > > When I, the programer who knows he is obeying > the clause of the contract that my company and > the supplier's have both signed (sic), then the > other party insisting that we should nevertheless > run their checks does not abide. I hope I never have to use a product that is purposely designed to be garbage. ... > The most important thing is, designing by contract > is *not* programming defensively. By definition. One *always* programs defensively. The compiler can eliminate the vast majority of the cost automatically, and what it can't eliminate demonstrates likely bugs. I'm aggresively pushing Janus/Ada in this direction (don't have enough free time to make a lot of progress though), as it combines the advantages of what CodePeer does with what an Ada compiler can do, without the possible disconnect of having different tools (which necessarily have to make assumptions about how the others work). The easiest level of that is described in an RR blog post from last June: http://www.rrsoftware.com/html/blog/quality.html. I'm working on some additional even more aggresive quality checks; I'll write a blog post on them when they're finished, hopefully sometime this winter. Ultimately, I'd like to include all checks and contracts in the quality checks, but that's going to require a lot of development time and probably will appear over multiple years and compiler versions. In any case, this is the exact opposite of the sort of approach that you are championing. It defeats the purpose of Ada, and it doesn't help that the client (in your scenario) is asking you to do that. It's still silly. Randy.