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

[jsa@alexandria (Jon S Anthony)]

In article <33343EE3.7DE14518@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Is it ever possible  to have a technical discussion without
> resorting to insults? Jon S. Anthony finds it productive to write,
> about one of my earlier messages:

Yes, it is possible, and I admit that you indeed did successfully goad
me into making these comments.  The frustrating part is that you just
simply deny some facts - over and over.  I'm not sure why you want to
deny them - it's not as if they make that much of a difference to your
overall case.  That is what goaded me into these statements.

Also, I have no problem whatsoever with your being biased toward
Eiffel here.  Both for technical reasons as well as business reasons.
I just don't understand why you should bother trying to deny it or
pretend that the paper in question is not rather blatently biased
against any other implementation language.  What's the point?  It's
not as if anyone actually believes these denials and they don't make
any difference to your position anyway (unless you are trying to
assume some air of objectivity in the matter??)


> It is this type of gratuitous attack that empoverishes Usenet and has
> the potential to destroy it. When people who know what they are talking
> about, and could contribute usefully to the debate, see this kind of
> absurdity, they refrain from participating. Everyone loses.

Indeed you are correct and I apologize here and now for doing the very
sort of thing that I have decried myself.  Ugh!  I am dooly (sp?)
embarassed.


> I assume Mr. Anthony's hope is that by making sufficiently outrageous
> statements he'll win by causing others either to lose their temper

No, on the contrary - it was you who successfully made me lose my temper...


> > Ada _has_ assertions.  Their form is not of the same syntactical look
> > as Eiffel's.  So what?  They take the form of constraints, in
> > particular (wrt to the case at hand) subtype constraints  
>  
> OK. Ada has assertions. Great news! I have read a lot about Ada but
> must have missed them. So let's see what their application would be
> to a typical example of Design by Contract.

Why not take the case in hand?  The Ariane one?  Perhaps because that
case is easily handled by Ada constraints?  Oh, by the way, you left
out the part where I clearly concede they are not as capable or
general as Eiffel's:

  "They are _not_ as flexible or full "featured" as Eiffel's but they
   are certainly there and in the Ariane case"

Any particular reason why you would want to do that?


> Take a class PERSON in a system for genealogical or demographical
> analysis. Here are some of the logical properties to be documented
> and enforced:

Hmmm, Clearly you are being nicely sarcastic here, but I never said
that Ada's "assertions" were as flexible and as widely capable as
Eiffel's.  So, this is a strawman and simply irrelevant.


> Now if Ada has assertions, how would you express the above properties?

Come on, who ever claimed that Ada's constraints are anywhere near as
capable as Eiffel assertions??  Quote anything anywhere of mine where
I even hinted at such a ridiculous claim.  In fact, I have often
stated (even in the message that started this) that they are much more
capable and that I think Ada95 goofed in not putting in some better
support for them.

BUT.  "Not as capable" does not mean does not exist.  A simple matter
that I am sure you would agree with.  In fact, "not as capable"
clearly implies they exist - lest there would not be anything to not
be as capable.  So, this entire example, is nice and quite good, but
has nothing to do with the topic or the point.  Ada does have
assertions and in the particular case at hand, the Eiffel you gave in
your paper has an _exact_ analogue in Ada.  I've stated it a couple
three times.  No point in repeating it again.


>         `assert not other.married'. Instead, we are interested in
>         associating with every software element - class or routine -
>         a precise specification, or "contract", describing
>         its obligations and benefits. The contract will serve as
>         help in the analysis-design-implementation process (as briefly
>         mentioned above), as documentation of the final software, as
>         aid in debugging - by turning on run-time assertion monitoring
>         in Eiffel environments -, as safeguard in using inheritance, as
>         a basis for exception handling etc.)

All of this is great and wonderful and I wish you had put the case
more like this in both your paper and in your subsequent comments on
news.  Perhaps the mistake was in using trying to use an inappropriate
example (Ariane failure) as somehow being a case where Eiffel
assertions would have saved they day when the evidence clearly
suggests they wouldn't have.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com