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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: dewarr@my-dejanews.com Subject: Re: Fortran or Ada? Date: 1998/09/26 Message-ID: <6uifdr$dog$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 395040824 References: <36068E73.F0398C54@meca.polymtl.ca> <6u8r5o$aa4$1@nnrp1.dejanews.com> <360A3446.8AD84137@lmco.com> <6udre0$ha1$1@nnrp1.dejanews.com> <19980925.185359.250@yktvmv.watson.ibm.com> X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sat Sep 26 10:25:01 1998 GMT Newsgroups: comp.lang.fortran,comp.lang.ada X-Http-User-Agent: Mozilla/2.02 (OS/2; I) Date: 1998-09-26T00:00:00+00:00 List-Id: In article <19980925.185359.250@yktvmv.watson.ibm.com>, jbs@yktvmv.watson.ibm.com wrote: > How come Fortran keeps getting blamed for a rocket failure > it didn't cause while no one blames Ada for the Ariane 5 failure > which it arguably did cause (Ada detected and mishandled a harmless > integer overflow which most Fortrans would have ignored)? > James B. Shearer Well as I made perfectly clear in my post, that this Fortran bug *caused* the mission failure is urban legend, but it did indeed cause a serious simulator failure at a late stage as I understand, and I think the point is clear that the language design is seriously defective in this respect, surely no one would contest that. The reason that Ada is not blamed for Ariane is that it is not at fault! The program performed according to its specifications, but it was the specifications that were faulty. Reusing a program without proper testing and examination of changing specifications is a bad thing regardless of language. I don't think you can make any very convincing argument that one language is more resiliant to this kind of incompetence than another! On the other hand, there is a useful lesson to be learned, not about any design weakness in Ada, but about how to use any language with runtime error checking carefully. Runtime error checking is a very powerful tool, but like any tool it can be misused. Enabling any kind of runtime checking, whether it is built into the language or into the program explicitly does not necessarily improve the reliability of the program, and indeed, as in the Ariane case, if you don't properly consider what to do if an error check fails, can even have negative effects. However, trying to argue that Fortran is superior *as a language* in this case because it would have zoomed on, computing with rubbish values, is not very convincing (not to mention that the particular code in question would not have translated directly into Fortran, because of the (to me rather surprising) lack of fixed-point support in Fortran. Arguing that Fortran is better than Ada wrt Ariane is a bit like arguing that CD ROM drives that swallow your disk are better than ones that have a tray that pops out, in view of the famous (but perhaps apocryphal) tail of the Gateway user complaining to Gateway support that his built in beer can holder on his computer had broken off! Just because someone can misuse a tool is not a good argument for a language that completely lacks the corresponding capability. Actually this still isn't quite fair, there really was no *misuse* of the runtime checking in the Ariane case. The original design had indeed considered and addressed the issue of overflow in this case, and proved that, given the specification, it was not a problem (this is generally the approach that one must take with such issues in a critical program). The fact that this issue was not revisited when the code was reused was a serious procedural error. Consider for example the following alternative scenario. Let's suppose that the check had been carefully turned off in the original code, after proving that the overflow could not occur anyway. Now when the code is moved to a situation where the overflow did occur because of unexamined changing specifications, then instead of signalling a trap, computation continues with garbage values. It is VERY easy to imagine a situation where this would be disastrous, and it would be *better* to signal an overflow, if the signal was caught correctly. When you make a very serious logic mistake in a program, the behavior of the program is often highly unpredictable, and it is difficult to argue about the language consequences, unless you could argue that the language could have prevented or discouraged the error, which is clearly not the case for Ariane. Note that if the program had been designed a bit better, so that the unexpected exception was caught and resulted in some appropriate fallback processing, Ada *could* legitimately be credited with providing facilities that saved the day, whereas a language like Fortran would have caused chaos by continuing to compute with wrong values. Despite the outcome, a proper analysis of the Ariane incident (isn't that a nice word :-) is actually favorable to the language design choices in Ada rather than unfavorable. So, that's why Ada doesn't get blamed for Ariane. It wasn't to blame. Now I agree that Fortran gets a bad rap for the Venus probe. Urban legends definitely grow over time. Who knows what people will say about Ada and Ariane twenty years from now :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum