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: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public From: Bertrand Meyer Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/21 Message-ID: <33330FE5.3F54BC7E@eiffel.com>#1/1 X-Deja-AN: 227385239 References: <332B5495.167EB0E7@eiffel.com> <332D113B.4A64@calfp.co.uk> <5gm8a6$2qu$2@news.irisa.fr> <3332BE49.8F9@lmtas.lmco.com> Organization: Interactive Software Engineering Inc. Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-21T00:00:00+00:00 List-Id: Like Jean-Marc Jezequel, I think Ken Garlington may be finding things in our article that are not there. [Ken Garlington quoting Jean-Marc Jezequel:] > > Unless our English is so bad that it betrays our thinking, we > > [i.e. Jezequel and Meyer] > > *never* implied such a thing. Just a point in a case: > > Eiffel simply did not exist when they > > worked on Ariane4. Let me quote the relevant section of the paper: > > > > << Is it the programming language's fault? > > << Although one may criticize the Ada exception mechanism... [Ken Garlington] > Interestingly enough, such a statement is not made about Eiffel > assertions, > although one could criticize those as well (or any feature of any > language, for that matter. You are picking on a sentence that explicitly says it is NOT the programming language's fault. It was important to note as an aside, as we did, that Ada's exception mechanism IS subject to criticism (many people have criticized it thoroughly, including Tony Hoare in his Turing Award lecture), but that this was NOT the point here since Ada's exception mechanism, in spite of its deficiencies, COULD have been used to avoid the error. > Interestingly, all of the coding examples are in Eiffel, although > apparently any language could have been used. Only a language that has built-in support for preconditions, postconditions and class invariants. > Or could it? From later in the paper: > >>>>"To attempt to reuse software without Eiffel-like assertions..." > ^^^^^^ > Note that these are not characterized as "design by contract-like" > assertions, but Eiffel-like assertions. The paper goes on to make it > clear that not just any language will do. Because not just any language will do. Of commonly available languages, Eiffel is the only one to have built-in support for assertions in the spirit of Design by Contract. This is a plain fact, not subject to disputations or to accusations of starting "language wars". (What is subject to discussion is of course everything else: whether it is useful to have assertions as part of the language, whether Eiffel's assertion mechanism is properly designed etc.) The paper as quoted above by Mr. Garlington explicitly talks about "Eiffel-like" assertions, not about Eiffel assertions. [Ken Garlington quoting from the Ariane paper by Jean-Marc Jezequel and me at http://www.eiffel.com:] >>>>"It is regrettable that this lesson has not been heeded by such recent >>>>designs as Java (which added insult to injury by removing the modest >>>>assert instruction of C!), IDL (the Interface Definition Language of CORBA, >>>>which is intended to foster large-scale reuse across networks, but fails >>>>to provide any semantic specification mechanism), Ada 95 and ActiveX." [Ken Garlington] > From this we learn that Java and Ada 95 are not properly designed for > Design by Contract. Which is the simple truth. The designers of these languages have explicitly rejected the inclusion of assertions. Why? They are the ones to ask. I am sure they must have their reasons (however unlikely it is I would find these to be good reasons). > What does a language need to support Design by Contract? We are told... >>>>"For reuse to be effective, Design by Contract is a requirement. Without >>>>a precise specification attached to each reusable component -- >>>>precondition, >>>>postcondition, invariant -- no one can trust a supposedly reusable >>>>component." > I wonder which languages have built-in precondition, postcondition, and > invariant statements... Eiffel, for one. People have tried adding these constructs to various other languages too, although none of these efforts has gained widespread acceptance. And of course in Eiffel they are not an add-on but part of the language's basic design (the inheritance mechanism, in particular) and methodology. It doesn't mean the concepts are worthless for people using other languages. If they were, no one besides Eiffel users would be paying attention to Design by Contract. (I don't mean to imply that Eiffel's assertions came out of the blue and that no one else has had related ideas. In a recent posting in a different thread I tried to give a reasonable account of the origin of the ideas, going back to the late sixties, and quoted other languages that have integrated neighboring constructs. The only one that is still active to my knowledge is Turing, although I haven't followed its recent developments.) > It's bad enough that you post statements that are explicitly > contradicted by the Ariane V final report (e.g. that the IRS could not be > tested in a black-box environment). When you post statements that are > contradicted by your *own* paper... No evidence has been furnished of either of the purported contradictions. -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, - ftp://ftp.eiffel.com Visit our Web page: http://www.eiffel.com (including instructions to download Eiffel 4 for Windows)