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

[Ken Garlington <GarlingtonKE@lmtas.lmco.com>]

Bertrand Meyer wrote:
> 
> 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), 

Anyone want to beat that chestnut to death, or is it worth the effort?

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

I am totally confused now. The Ariane V incident could only have been
prevented by a language that has Eiffel-like constructs, but it wasn't
the language's fault?


> 
> > 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".

So, the paper does make a statement about the preferred language? Then
why does the co-author state (as you did earlier, in fact) that the
language did not matter?

This must be a language barrier, because I hear you contradicting
yourself
in the same post.

It should be noted that the term "language wars" was brought up
by your co-author. My criticisms have been solely in two areas:

1. Eiffel assertions would not have saved the Ariane 5, all other
   things being the same.

2. Although the co-authors claim that their web page is about a
   design technique that can be implemented in any language, they
   contradict themselves both in the paper itself and in subsequent
   posts.

> (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.)

I posted a detailed critique, using quotes from the report, addressing
whether "it is useful to have assertions as part of the language",
specifically in the case of the Ariane 5 incident. There has been no
response.

> 
> 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).

Again, you hammer home the point that there is only one language which
is appropriate for solving the Ariane 5 problem, contradicting your
earlier statement.

I will freely admit that Eiffel is required for Design by Contract. Why
do you hestiate to do the same? In fact, would it not be more accurate
to simply state your position as: "If the Ariane V had been programmed
in Eiffel, with proper use of Eiffel assertions, then the incident would
not have happened?"

Why be so oblique in your paper? Simply make this assertion, give the
address where to order copies of Eiffel, print it on color glossy paper,
and send it to all the major aerospace companies? It seems
intellectually
dishonest to say "this is not a language issue."

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

So, the only language with widespread acceptance that properly supports
Design by Contract is Eiffel. Again, you prove my point. I'm glad we
can agree on this.

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

Why should non-Eiffel users pay attention to Design by Contract, if
other
languages do not properly support it? Is it your intent that software
engineers use inferior tools?

> 
>         (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.

Your co-author has at least partially conceded the testing point in
another
post. There are many other objections I could make to the paper, but
since
neither you nor your co-author have responded to the list of barriers to
assertions I posted previously (and in a mail message to you when the
IEEE
column was originally published), I assume they will not be addressed.



> 
> --
> 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)

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com