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

[milkweed@plainfield.bypass.com (Anders Pytte)]

In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

In a few hours my team developed much of the functionality of Eiffel's
assertions (certainly the most essential functionality) for our C++
project by using macros. With minor changes, I could apply them to the
problem suggested by Bertrand as follows. Show me how this will not work,
please!

The macros, which can offcourcse be turned on or off according to compile
switches:

ENTER: Sets up data structures to register requires by name so they can
override requires of the same name in calls to inherited method.

REQUIRE, ENSURE, INVARIANT: Registers name (check to see if overridden)
and handles false expression with exception, program break, or other
means.

EXIT: Cleans up data structures created by ENTER and calls CheckInvariants().

The class (note that CheckInvariants() may be overridden):

class Person
{
private:

   EGender gender;
   EStatus status;
   Boolean married;
   Person spouse;

protected:

   virtual void CheckInvariants()
   {
      ENTER(Person, CheckInvariants);

      INVARIANT(married_iff_has_spouse, married == (spouse != NULL));
      INVARIANT(married_to_spouse, !married || (spouse.spouse == Current));
      INVARIANT(married_to_other_sex: !married || (gender != spouse.gender));

     EXIT(Person, CheckInvariants);
   }

public:

   void Marry (Person other)
   {
      ENTER(Person, Marry);

      REQUIRE(available, !married);
      REQUIRE(other_exists, other);
      REQUIRE(other_not_married, !other.married);
      REQUIRE(different_gender, gender != other.gender);

      // the wedding...

      ENSURE(married, married);
      ENSURE(married_to_other, spouse == other);

      EXIT(Person, Marry);
   }
}

I would prefer using Eiffel, but I agree with Jon Anthony that the same
practices (use of assertion for design by contract) are available from
alternative languages. Getting this concept across to Eiffel language
fiends can be exasperating!

In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

> Is it ever possible  to have a technical discussion without
> resorting to insults? Jon S. Anthony finds it productive to write,
> about my earlier messages
> 
> > Do you have any idea how ridiculous this sort of statement makes you
> > look???
> 
> further, that my comments are
> 
> > extremely disappointing and make [me] look [again!] ridiculous.
> 
> and that I am
> 
> > just plain a) wrong or b) - well it doesn't take a genius to fill in
> > the obvious answer to this option.
> 
> 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.

I think a real problem we have in our discussions is that the cleverest
among us are also the best at convincing themselves of there own
correctness even when they are wrong. Sometimes the best antidote to those
who hide behind seemingly inviolable intellect is to stoop low when
dressing down - it reminds us of our human-ness.

While I agree in principle that we all gain by observing standards of
mutual respect in our discussions, there are subtle forms of bullying
practiced by the most trenchant of contributors whose refinement seems to
elevate them above the level of smut and insult here criticized by
Bertrand.

A good example is the paper in question: many readers, including myself,
immediately detected an incorrect _attitude_ in the paper, even though it
is so well guarded as to utterly defensible. Mr. Anthony accurately
described how that attitude was projected. His observations are obvious to
me but difficult to defend, because they stray into the realm of humanity.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com