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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Ada and Automotive Industry Date: 1996/12/03 Message-ID: <32A459BC.7D73@lmtas.lmco.com> X-Deja-AN: 202120909 references: <55ea3g$m1j@newsbf02.news.aol.com> <3280DA96.15FB@hso.link.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada,comp.realtime x-mailer: Mozilla 2.02 (Win95; I) Date: 1996-12-03T00:00:00+00:00 List-Id: Chris Hills wrote: > > As I said several times it does not matter how THEORETICALLY safe a > language is if the implimentation and the supporting tools are bug > ridden it is of little use to anyone. Since I've made this same argument myself, I could hardly object. However, I thing you're missing the point. At some level, we should be able to talk about the definition of a language independently of its implementation, just as we can talk about the definition of any other software-based system independently of its implementation. For example, when I do a review of a flight control system design with our customer, I can talk about how the design protects against certain kinds of faults, what the techniques we use to assure the integrity of the design, and so forth. Of course, if I implement the design incorrectly, it's not going to work, but that doesn't mean I can't say _anything_ about safety or reliability before I implement the system. The same holds true for languages. Ada, at the language _definition_ level, provides many features that help develop safe and reliable software. A buggy _implementation_ does not change this, any more than the existence of CPUs with buggy microcode means that all software-based safety critical systems are inherently unsafe. You're right; a solid compiler (in any language) is better than a buggy one. However, I would prefer a solid Ada compiler to a solid compiler in some other languages. When comparing _languages_, as opposed to implementations, you have to divorce the language itself from a particular implementation. > I could depend on the REAL (as in it had a customer and HAD TO WORK in a > real environment) program written in C but we could not depend on the > same program in Mod2 because the develpoment system was bug ridden. In > other words the Mod2 program would not perform as the language dictated > and the program was unsafe. Assuming that the Mod2 tools did "perform as the language dictated," would you rather have used the Mod2 or the C program? > Your Item "c" shows aragance beyond belife. "whose answer should be > clear to anyone who understands the language". Obviously the > description specification was not clear. Actually, an implementation may be wrong even if the specification is "clear" (whatever that means), so I'm not sure it's so "obvious" that the language is unsafe just because of a poor implementation. Note also that the existence of standard test suites such as ACVC does help to check that the Ada specification is consistently implemented, although like all test suites it's not a guarantee. > If any *one* person can make > the mistake so can another, meaning that in implimentation the result > may not be the same. However, this argument can be used for any compiler (or any system, for that matter), so it's not a particularly good criterion for choosing one language over another. > I may not understand "AT ALL the concept of saftey in the design of a > language" but my sw has to run and work without error day in day out. > (My current Sw when finished is expected to run for 15 years from switch > on (24 hours a day) with down time of 15 min a year for planned > upgrades). The last system I did (also in C) has run for 2 years without > problems. Certainly, there are safe systems in C, or in assembly for that matter. The real issue is, what languages make it _easier_ to create safe and reliable systems? It is possible to swim the English Channel, but most people prefer alternative methods to cross it... > The Ariane 5 rocket had Ada Sw (a "Safe" language) and crashed after 39 > seconds (a bit of a red herring as Ada was not directly to blame and the > same could have been done in C or Mod2) SO what is the excuse here? the > Sw team did not understand the use of the language? Actually, the "excuse" is (1) The inertial system was used in an environment outside its original specification and (2) the system was never tested in the new environment to see if it would work. Again, it's not a meaningful argument. No one says that Ada is a guarantee of absolute safety, since safety is not an absolute. Any system will eventually fail when operated improperly. Try as I might, I can't build a flight control system that is "crash-proof." However, I can build a system that keeps the plane in the air as long as is reasonable for a given set of conditions. > If it is that hard > to use and that easy to miss use it is unsafe in practice. Nothing in the Ariane 5 report indicates that Ada is "hard" to use. What language do you propose that makes it "easy" for a system to perform properly outside of its specification? > As I repeatedly say the theory is fine (it's what accademics are good at > :-) but is it safe in practice? Actually, yes. There is a substantial and growing set of real-world safety-critical systems written in Ada, which are performing quite well. See the list of Ada systems on the Ada WWW servers. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" See http://www.lmtas.com for more information (job listings now available)