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: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/17 Message-ID: #1/1 X-Deja-AN: 226282589 Distribution: world References: <332B5495.167EB0E7@eiffel.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada,comp.lang.java.tech Date: 1997-03-17T00:00:00+00:00 List-Id: In article <5giu3p$beb$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc Jezequel) writes: > In article , dewar@merv.cs.nyu.edu (Robert Dewar) writes: > >Thomas says > > > >< >had used Eiffel preconditions, the rocket would not have crashed. > >You suggest a precondition of the form:>> > > > >Indeed .. anyone can argue that their favorite language, if used properly, > >would have avoided the Ariane 5 bug. That's true even for assembly language. > > > >The fact of the matter is that this bug was a result of the approach > >used, and had nothing to do with the particular language chosen. Indeed > >the Ariane 5 crash serves as a useful reminder that Ada is not some magic > >panacea that prevents incompetent design and implementation! > > I agree with Robert Dewar. Please do not start a language war! It Agreed. That sort of moronicy is the _last_ thing we need. > is made crystal clear in the paper that > *THIS IS NOT A LANGUAGE PROBLEM* > let me repeat it in case it is not clear: > *THIS IS NOT A LANGUAGE PROBLEM* Exactly. And this has been discussed to death and the same conclusions reached several times. > The all point of the paper is that Design by Contract helps in the > precise specification of components: signatures (a la CORBA) are not > enough to specify a behavior, pre- and post conditions are needed to > give more details. Yes, CORBA style interface specifications are no help here whatsoever. None. Zero. The problem revolves around explicitly capturing the semantic context of the "components" so that (re)usage of them will not go beyond that prescribed scope. This is non trivial and NO, repeat NO, programming language currently has more than the most primitive support for even the most rudimentary aspects required for this. While certainly better than nothing, pre and post conditions should be seen as merely an example of such rudimentary capability. > I'm willing to discuss this last point, but I will not answer any > language issue in this thread. Seems reasonable to me. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com