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: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: Richard Riehle Subject: Re: Ariane 5 - not an exception? Date: 1996/08/20 Message-ID: X-Deja-AN: 175474596 references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <4tiu6e$kpm@news2.cais.com> <4up8pi$lvi@goanna.cs.rmit.edu.au> content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 reply-to: Richard Riehle newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 Date: 1996-08-20T00:00:00+00:00 List-Id: On 13 Aug 1996, ++ robin wrote: From: Richard Riehle Robin wrote in response to my posting regarding PL/I for Arianne: > > > 2) PL/I > > > a) There is no PL/I compiler for the 1750A > > ---Not an obstacle. How was an Ada compiler written for it? There are many Ada compilers for the 1750A from many different compiler publishers. And there is considerable experience using Ada for this architecture. The unavailability of a PL/I compiler is very much an obstacle to using it. Moreover, PL/I has plenty of problems of its own. From an engineering viewpoint, little nuisances such as "default identifiers," the ability to reference an unknown name outside a nested block, side effects created by "secret" variables, the poor facilities for explicit scope resolution, the unpredictability of "partial qualification," etc. I could go on for several pages, but this should give some idea. PL/I, when used carefully, has been used successfully for a wide-range of important applications, but it is not without a substantial number of warts and imperfections. Once again, I have not used PL/I for a long time, so some things about the language may have gotten better. > > b) Ada is far more suitable for safety-sensitive > > software than Pl/I > > ---Nonsense. PL/I has a long (30 years) record in > excellent real-time facilities, and with people with > experience in error-recovery and fail-soft in routine > commercial applications as well as real-time programming. And there is far more successful experience using Ada for this processor architecture than there is PL/I. Moreover, Ada is explicitly designed for safety-sensitive software. Moreover, Ada's track record in safety-critical real time systems is excellent and getting better all the time. > > c) This failure was not a language issue. > > ---Isn't it? One of the arguments put forward was that > an Ada condition couldn't be raised and leave a trace, > and that it would be argued that there was no guarantee > whether a piece of code was executed. Vis a vis the Ada language, that is an incorrect statement. > > In PL/I, a SIGNAL statement (which can be used for > program checkout) leaves a printed record that it was > executed. It gives a message that the condition was > raised, and comes with line numbers, etc. There is > absolutely no doubt that the statement did not execute! So who gets the message? Where is it stored? Printed record? Now that is interesting. It reflects a mainframe point-of-view rather than an embedded systems point-of-view. We seldom include a printer on a space bound system. On the other hand, we do collect a lot of telemetry data, and this should be available. However, it would have been of little use for Arianne V since no one would be using it for corrective action in time to save the system. > ---There are lots of things for which one can blame > management, but the lack of a check for overflow has > to come down to the programmer. Wrong again. In an data processing system, we give the programmer greater latitude. In this kind of application, the programmer is a contributor, but not a final authority. This is engineering, not programming. Or it should be. >> d) Given the incorrect specifications against which the program was >> designed, the same failure would have occurred in PL/I or any >> other language. If a programmer decides, independently of the specifications, the systems engineering designers, the V & V team, and his peer review group, to include unapproved code with such serious implications as error correction, that programmer will never work on this kind of project again. > > overflow. A R/T (and even non R/T) PL/I programmer > routinely puts in error control. This is not the exclusive province of PL/I programmers. I am amazed at such a narrow view. Error management is a well-known part of programming, and Ada has excellent facilities for doing it. Facilities every bit as good, perhaps better ( I have written PL/I in my ancient past) than PL/I. However, the programmer may alert the development team to a potential error, but this software is the work of a team of engineers, not the independent creative effort of some single programmer. > ---In this case, with simulated inputs, and with SIGNAL > statements to check out what happens when an interrupt > occurs. If this had been done (routine in PL/I), the > effect of an unchecked conversion would have been observed. Apparently, as I have learned from another post and a face-to-face conversation with one of the engineers on the project, this was not a function of unchecked conversion, so that is moot. > > 7) Ada > > > This is still the best language for doing this kind of system. > > ---PL/I would be clearly better, as it meets the requirments > for audit trails in program and system checkout (in addition > to the other facilities that it offers). Frankly, I am still baffled by this argument. It is increasingly clear that your knowledge of Ada is somewhere between sparse and none. PL/I was well-known at the time a decision was taken to bypass it as a choice for the new DoD language in the late 1970's. Why? I can think of lots of reasons, but they would be lost on anyone who is not ready to acknowledge their validity. In response to my comment regarding the role of management in this failure, you reply, > ---Scarcely convincing, in view of the failure. Well, it had better be convincing to someone. If I understand my understanding as I think I understand it, the failure was a direct result of assuming that software which behaved correctly for Arianne IV, would also work correctly for Arianne V. This assumption was made in spite of the fact that Arianne V was designed with a different set of launch behaviors that Arianne IV. On Arianne IV, the software, at the point where the overflow would be detected, was designed to shut down the system while it was still on the launch pad. Due to differences in launch behavior, this same software shut down the system after lift-off. The software behaved exactly as it should for the Arianne IV. It was an engineering error to use the same software, unchanged in a system with different launch characteristics. No programming language can tell the engineers they are making such a fundamental error. Even your beloved PL/I would have failed under these circumstances, unless it has taken on far greater run-time intelligence than I recall. Richard Riehle