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-27 10:13:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.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: Fri, 27 Jun 2003 10:15:59 -0700 Organization: AdaWorks Software Engineering Message-ID: <3EFC7BCF.6B038EED@adaworks.com> References: <3EF5F3F3.6000806@attbi.com> <3EF7F94D.5080105@attbi.com> <3EF88A7E.5060304@attbi.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 3f.bb.a0.ee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 27 Jun 2003 17:13:00 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:39831 Date: 2003-06-27T17:13:00+00:00 List-Id: "Robert I. Eachus" wrote: > But to me the crowning idiocy of the whole thing is in one sentence of > the report: "The main explanation for the absence of this test has > already been mentioned above, i.e. the SRI specification (which is > supposed to be a requirements document for the SRI) does not contain the > Ariane 5 trajectory data as a functional requirement." Since this discussion began as a dialogue about the Boeing 7E7, and someone raised the question of whether C++ would be appropriate for software on that aircraft, the lesson of Ariane 5 is important for the engineers. First, let's make clear that JSF is not being programmed in C++ but in a very limited subset of C. Some of the JSF systems will be programmed in Ada, but not as many as one might expect if the JSF engineers were using better judgement. Second, we have the issue of reuse, as noted by Hyman Rosen in his mistaken appraisal of the Ariane 5 failure. I and others have commented on this earlier. If Boeing does decide to use Ada, and we would hope they would, the lessons of Ariane 5 are valuable. Those lessons indicate that, even when using superior technology, one can make other engineering decisions using incomplete data. C++ would be a dangerous choice, not only because the language itself can lead to so many undecidables and unpredictable fragments of code, but also because the language, itself, implies a heavy reliance on resuable components. Frankly, I have greater confidence in the savvy of Boeing engineering management and would expect them to have learned the lessons of Ada from the B-777, along with the lessons being learned in the on-going upgrades (in Ada) of software for the B-757, B-747, and B-767. As far as I know, there is no DO-178B compliance inherent in C++. One can comply with DO-178B using a carefully selected subset of C. Even in Ada, one must take care to apply the appropriate pragmas from Annex H, apply the constraints of Ravenscar or SPARK, and avoid certain low-level features of the language a less experienced engineering might be tempted to engage. C++ might be appropriate for certain systems such as cabin entertainment, but it would be a serious error in engineering management to choose it for any of the safety-critical software. The more I see of C++, the more experience I gain with it, the more I realize why Ada is designed to a more rigorous set of rules. Those rules may be annoying to some programmers, but those rules make sense to an engineer. A fly-by-wire aircraft is an engineering problem, not a programming problem, even when software (and programming) are part of the solution space. When one looks at this kind of system as a total engineering effort, one must also consider the software as part of the engineering, not separate from it. With C++, it is too easy to disengage the software effort from the rest of the engineering effort. The argument that one cannot find trained and experienced Ada programmers is one of the most bogus arguments proposed by military and civilian contractors. We are looking first for engineers. In my experience, good engineers, when exposed to Ada, do learn to create excellent software designs, and they learn to do so independent of the the search for the perfect algorithm. Often, it is better to start with engineers and teach them Ada than to start with programmers who have already developed bad habits. I see lots of C++ programmers who have to be re-educated to think as engineers when given problems in embedded systems environments. I have trained engineers to program in Ada and they take to it well and understand the underlying rationale for its design. I have trained C++ programmers and many of the spend their time arguing about how they can do such-and-such in C++ and why can't they do it that way in Ada. We can train experienced programmers in Ada, but we need to first train them to think like engineers. It seems that, many engineers grasp the reasons for Ada's design quickly. Those same engineers are not focused on resume-building, but on problem-solving. They realize that Ada is an excellent tool for solving engineering problems. For the past three years, I have been teaching Ada at the Naval Postgraduate School., My students take Ada As A Second Language. At the end of each Quarter, I require them to write a paper comparing Ada with their first (or other ) language. They often express their preference for Java (rarely for C++), but most of the understand the difference between using Ada for dependability and Java for ease of creating screens and little GUI programs. I believe that the Boeing engineers also understand this. They are building software where life and safety are at stake. When one objectively examines the current choices in software engineering languages, Ada continues to be the most appropriate choice when one is concerned with high dependability. Let's hope I am right about those Boeing engineers. They have shown good judgement in the past in making software decisions. They will probably continue to do so in the future. Richard Riehle