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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!news1.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread3.news.pas.earthlink.net.POSTED!01cc3b7c!not-for-mail Reply-To: "Richard Riehle" From: "Richard Riehle" Newsgroups: comp.lang.ada References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> <1094529422.982635@yasure> Subject: Re: ADA Popularity Discussion Request X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <_xl%c.431$xA1.301@newsread3.news.pas.earthlink.net> Date: Tue, 07 Sep 2004 16:42:34 GMT NNTP-Posting-Host: 66.81.217.106 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.pas.earthlink.net 1094575354 66.81.217.106 (Tue, 07 Sep 2004 09:42:34 PDT) NNTP-Posting-Date: Tue, 07 Sep 2004 09:42:34 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.lang.ada:3442 Date: 2004-09-07T16:42:34+00:00 List-Id: "Benjamin Ketcham" wrote in message news:1094529422.982635@yasure... > Richard Riehle wrote: > > > > 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. > > While I agree with the overall point here, I keep seeing this > assertion, here made with especially great conviction: "it is > impossible to test for the unexpected". As with many absolute > statements, it is not technically correct, although it expresses > a valid general truth. Consider the method of kernel testing > where system calls are invoked with random arguments; this kind > of test often turns up "unexpected" problems. Yes, Benjamin, I may have been a little too over the top in my use of the word, "impossible." I too have seen test plans and test scripts that randomly traverse that entire universe of possibilities to make sure that none of the unwanted combinations of keyboard entries (or other data sources) are allowed to pass at run-time. One of the benefits of assertions (DbC) is that one can simply declare a range of unacceptable conditions as part of the design and be assured that those conditions will not be permitted to occur. Even so, whether programming with assertions, or using a test-driven approach, one needs to be a little careful about depending too much on the tests or the assertions. Moreover, a well-designed program must be about more than simple correctness, even as hard as that is. Much has been said, in this forum, about the wonders of test-driven design in dynamically-typed languages as a benefit to on-going change in a program. In other forums that deal with this topic, advocates of TDD include refactoring as one of the mechanisms of choice. No reasonable person will deny that, under some circumstances and for some kinds of software, these are acceptable models of development. We are always compelled to ask about the limits of any tool, method, or style. To answer, "There are no limits," is to consign oneself in the league of the naive. Static typing, design by contract, and other static methods are certainly limited in what they can accomplish. So too, we must recognize the limits of the dynamic approach. As we examine those limits, for both approaches, we are required to also examine the trade-offs and risks associated with them. Is one approach more dependable for a given domain than the other approach? Is one more economical than the other for the context in which it will be used? This kind of inquiry is not unlike any other engineering exercise. We are in pursuit of a predictable outcome, an outcome that satisfies a defined set of requirements. Whether those requirements are specified as the tests themselves (as in TDD), or embedded within the assertions (as in DbC), in the type definitions and associated methods, or some combination, the goal is the same. Engineering is concerned with design. Engineeering prefers, as much as possible, settled knowledge rather than a continual test-debug model. We try to get the design as close to correct early, even testing parts of it along the way as we build it. However, testing every aspect of the design is not always possible. In particular, as the deployed design is required to deal with the real world, it must be able to adapt itself to the unexpected. Let me give you an example. In am system I know something about, one with a large number of components, a programmer included a routine that had a built-in constraint (not a type constraint), in the form of an if ... end if statement. The constraint was cleverly written and the language in use was not strongly typed, so the programmer could use long (as in long integer) as a reasonable data type for his algorithmic mischief. I say mischief because that was what it was, a small time-bomb intended to crash the program long after he resigned and went on to another job. No amount of testing would have caught this. He was clever enough to see to that. The design was not type safe, so the result from his routine could be easily passed to some other routine as a parameter. You many argue to the contrary, but the test scripts (well-designed) did not catch the error. When it occurred, the system failed, and no one knew why until a considerable amount of analysis was performed. Experienced software designers could easily relate many more such stories. Engineering history is full of them. Knowing that, in the world of physical engineering, where we are constrained by physics and can measure everything down to very fine tolerances, and still make disastrous mistakes, how do we justify any approach to software engineering that limits us to a single approach to creating dependable software? This question is especially important with the increased use of software in safety-critical systems. Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast, or their ilk will persuade the designers of flight avionics to begin using those languages. It is bad enough that some of them have chosen to use C and C++. We need to, as always, select the right tool for the job at hand. Richard Riehle