Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer <bertrand@eiffel.com>]

Anders Pytte wrote:
 
> I am objecting to the implication of the [Jezequel/Meyer] paper,
> made explicit in Meyer's further remarks in this thread, that the
> use of a language with "built-in support for assertions in the spirit
> of Design by Contract" would have prevented the Ariane-5 crash.

Especially since the presence of quote symbols carries an impression of
accuracy, please don't put words in our mouth that are not ours, even if
they seem at first to sound like ours. The relevant extract from our
paper at http://www.eiffel.com is

        !! 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.]

which anyone can see is significantly different ("language and method",
and "probably yes", with caveats about the risk of inferences, and a
careful point-by-point discussion to examine the reasons for the
assumption).

A friend forwarded to me the following extract from an ongoing
discussion on
the mailing list for the programming language Python, which may be
relevant here:

        >>> From: Fredrik Lundh <Fredrik_Lundh@ivab.se>
        >>> Cc: python-list@cwi.nl
        >>> Subject: Re: Guido's assertion proposal
        >>> (Was: something silly...)
        >>> Date: Thursday, March 20, 1997 1:22 AM


        >>> Paul writes (on "programming by contract"):
        >>> >||| This is the view of the software from the point of
        >>> >||| view of a potential customer for its services.
        >>> >||| If I call it
        >>> >||| with the require clause satisfied, I know it will not
        >>> >||| return to me unless the promises it makes in its
        >>> >||| ensure clause are true. As libraries of
        >>> >||| components grow, the ability to see this "contract"
        >>> >||| is the key to enabling reuse
 

        >>> This is probably the most crucial part in the
        >>> "component oriented design" (or maybe "interface oriented
        >>>  design") school that I happen to
        >>> subscribe to; you cannot *reuse* things if you don't
        >>> know *exactly* what they are supposed to do.
        >>> Some fascinating reading on this can
        >>> found in the following article by Meyer/Jezequel:

        >>>
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

        >>> (read it, and if you think they say "this wouldn't
        >>> have happened if they'd used Eiffel", read it again ;-)

I think the last two lines are good advice...

[In the quotations I have reinstituted the spelling of my name,
of Jean-Marc Jezequel's, and of Ariane.]
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)