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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f948976d12c7ee33 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-29 11:23:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-pas-nf2!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: Boeing and Dreamliner Date: Sun, 29 Jun 2003 11:26:54 -0700 Organization: AdaWorks Software Engineering Message-ID: <3EFF2F6D.3793971@adaworks.com> References: <3EFC6FC2.B96DAEA4@adaworks.com> <1056731513.272294@master.nyc.kbcfp.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 3f.bb.80.d5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 29 Jun 2003 18:23:52 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:39896 Date: 2003-06-29T18:23:52+00:00 List-Id: Hyman Rosen wrote: > Alexander Kopilovitch wrote: > > This is a correct sentense, it conveys truth, but in such a way that you can't > > dissect it or extract contiguous part of it without converting the truth to a > > lie. Actually, the SRI software code for Ariane 4 was *perfectly good for > > Ariane 4*, although it quite probably was not so good in general -- so your > > sentense "It was not perfectly good code." is probably true also. > > The Araine 4 programmers exactly reproduced the Y2K problem in microcosm. > They wrote code that took advantage of limited input range, and sent it out > into the world with insufficient protection against the future. It was > perfectly good in the same way as two digit years. A key difference between designing in Ada and many other languages is the use of problem-space constraints. For example, a designer might declare an integer type such as, type Number is range 12..451; if the problem under consideration called for that kind of constraint. If, at some later time, I decide to use the solution bounded by that constraint to solve a problem that requires a different set of constraints, I will have made a mistake. The mistake, in that case, is mine, not that of the previous designers. What we often encourage, for Ada designs, is that the algorithmic details be independent of some particular set of constraints. Generic components are sometimes useful for this. For example, generic type Num is range <>; function Compute(Data : Num) return Num; where the internal algorithmic construct will behave exactly the same way on every instantiation of Compute after associating the generic formal parameter with a generic actual parameter. Putting aside the option of designing with generics, since many in the safety-critical community distrust this language feature, the issue of specifying constraints that precisely map the solution-space to the problem-space continues to be a useful feature of the language. If I accept this constraint during development, many potential problems will be identified early in my process. If, on the other hand, I choose to bypass the language safeguards and use unchecked features of the language, I am putting my entire design at risk. This is one aspect of the Ariane 4 software that contributed to the Ariane 5 event. The developers of the Ariane 4 software took the trouble to ensure that the unchecked operations were appropriate. The engineers on Ariane 5, many of who were the same people from Ariane 4, failed to evaluate the potential consequences of those same unchecked operations. Is this a failure of the language. One might suggest that the option of unchecked operations in Ada is a language problem. However, we must also recognize that the language clearly specifies that unchecked operations are "unchecked" by the compiler. In most languages, such unchecked operations are the default, not an option. For example, in the C family of languages, automatic type promotions rarely present any kind of warning to the programmer. In Ada, the programmer must bypass the normal rules of the language to achieve the same result. So, the software design for Ariane 4 was exactly right for Ariane 4. It was not designed for some future system. To suggest that this is the equivalent of Y2K is interesting. It re-raises some issues related to the original subject of this thread, that of the Boeing 7E7 and Boeing 777. And those issues directly support the folly of even thinking about using C++ for this aircraft. They also indicate where caution should be the watchword when transitioning 777 software to the 7E7. As I indicated in an earlier posting, I am confident the Boeing engineers will understand the lessons of Ariane 4/5 when re-using Ada code from the 777 on the 7E7. I am also confident that, pressures from resume-builders notwithstanding, they will realize the value of using contemporary Ada, with its excellent record for software safety, instead of a language so characterized by unpredictability that they could never be sure that some undetected behavior might manifest itself long after even the best of testing has been completed. Richard Riehle