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: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/24 Message-ID: <97032415151177@psavax.pwfl.com>#1/1 X-Deja-AN: 228067235 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-03-24T00:00:00+00:00 List-Id: Bertrand Meyer writes: > !! Does this mean that the crash would automatically have > !! been avoided had the mission used a language and method > !! supporting built-in assertions and Design by Contract? > !! Although it is always risky to draw such after-the-fact > !! conclusions, the answer is probably yes: > > !! [Detailed reasoning omitted.] > O.K. Here's my question: When the project team comes up with the answer that assertions and/or Design by Contract (whatever your favorite Eiffel-ism is) costs too much CPU time and hence needs to be turned off lest the software doesn't run at all, is there a way to do it? If there is no way to disable the features mentioned, is there a way to get straight into assembler from Eiffel so that the code can be written without the assertions and/or Design by Contract? If there is no way to disable the features and there's no way to get to assembler, is there some way I can pay the compiler writer to give me a custom switch to disable the features or get to assembler and thus avoid the checks? If the answer to the above questions is "No", "No", and "No" then you have just explained why Eiffel could never be used to develop the Ariane software. The design team *knew* that the runtime checks for valid data ranges were too costly in the particular application and hence needed to be disabled. They deliberately chose to ignore all of the possible features of Ada (or any other language for that matter) that could perform range checks and insure the data could never be wrong. This sort of thing is done *all the time* in the realtime world and insisting that one should *never* turn off runtime checks is displaying a lack of understanding about hard, realtime applications. Hence, I would conclude that Eiffel *could not* have saved the Ariane, because it was a deliberate, conscious, decision on the part of the design team to exclude runtime checking. No language could have saved them. On Ariane 4, the decision was one valid way to build the software. On Ariane 5, they messed up by assuming there was no difference from Ariane 4, and thus they could reuse the software. When folks sit around and discuss language theory and software design strategies or methodologies, they often come up with really good ideas. But in real applications, you very often have to back off of what is "theoretically pure" because of real world constraints. And that sort of "backing off" would happen no matter *what* language gets used. MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 M/S 731-96 Technet: 796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 P.O. Box 109600 Internet: CONDICMA@PWFL.COM West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM =============================================================================== In Vegas, I got into a long argument with the man at the roulette wheel over what I considered to be an odd number. -- Steven Wright ===============================================================================