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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews2.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 14 Sep 2004 13:14:54 -0700 Organization: http://groups.google.com Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> NNTP-Posting-Host: 198.23.26.253 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1095192894 21885 127.0.0.1 (14 Sep 2004 20:14:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 14 Sep 2004 20:14:54 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3734 Date: 2004-09-14T13:14:54-07:00 List-Id: "Richard Riehle" wrote in message news:... > "Kevin Cline" wrote in message > news:e749549b.0409051449.574ec9ce@posting.google.com... > > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message > news:... > > > > But assuming perfect testing, finding the errors during compilation > > > rather than in testing saves me time, and time is money. > > > > I thought so too, until I tried incremental test-first development. > > Retesting a unit after adding a few lines of code means that type > > mismatches are caught immediately with or without strong typing. But > > it goes faster if you don't have to compile and link every iteration. > > > This assumes that we are concerned only with type mismatches. In > Ada, we expect the compiler to provide a great deal more than that. > > For small software systems, frequent testing can often be sufficient. As > the size of the software increases, and complexity of that software grows, > we must engage all the tools available and use them appropriately to > ensure the correctness of our design. Also, in large software systems, > it is not possible to test every path, every possible value of a variable, > and every potential timing problem. > > How does one test for a race condition? I don't test for race conditions. I try to isolate code potentially subject to race conditions or deadlocks to a small program unit, and then, if necessary, prove it correct. > Does that test guarantee > no race condition can occur? > This is not a type checking issue, but > it is a design issue where the type model can be one of many factors > in reasoning about the stability of the design. > > How does one test for a runaway pointer or dangling reference? I don't test for these. As a general rule, I don't write code that would make them possible. When I do have to write unsafe code, then I encapsulate it tightly so that the code is either obviously correct or can be verified correct in short order. > Again, > this is not strictly a type issue, except that Ada's overall set of rules, > including the type rules, provide some tools for reasoning about this > intelligently. Working safely with dynamically allocated objects in Ada-83 means using unhecked_allocation and deallocation, which reqired almost as much diligence as using malloc/free in C. Then C++ appeared with constructors and destructors and auto_ptr, and memory management got a lot easier. Then Ada-95 added controlled types, but by then C++ had huge mindshare. > Finally, testing can only test for what we know needs to be tested. We > must design for the unexpected, even as we test for the expected. It is > impossible to test for the unexpected. The Ada type model includes > both the compile-time checking and the run-time checking. The rest > of Ada provides a wide range of compile-time checks. > > Those who fail to understand this should stay away from building software > that requires a high degree of dependability. What do you mean by the unexpected? It seems that everything that could happen to software can be anticipated, except for total failure of the underlying execution engine. Or do you mean unexpected exceptions or incorrect values returned by unexpected software errors?