Re: Critique of Ariane 5 paper (finally!)

Re: Critique of Ariane 5 paper (finally!)

[aek]

In <dewar.872088939@merv> dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>In this particular case, the very reasonable point that DBC may be a
useful
>tool in helping to achieve reliability in some circumstances
                                        ^^^^^^^^^^^^^^^^^^^^^
This is the point. When one claims that some new method or tool may be
useful
in some circumstances he seems to be obliged to describe those
circumstances
more or less precisely. But if one claims that this new method or tool is
very
useful universally then he frees himself from this trouble and invites
other
people to do this job.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia


\x1a

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Critique of Ariane 5 paper (finally!)

[Robert S. White]

In article <33FC66AD.9A0799D4@calfp.co.uk>, nickle@calfp.co.uk says...

>Let us say for the moment that in some circumstances DBC helps.
>For those that have been critising DBC, since DBC is optional, and is an
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  Nobody that I know of on this thread has been "critising DBC"!
What all the furor is about, is the claims that DBC _must_ be
used to create reliable software.  

  Ken, myself, and a few others have been arguing that you can 
not always employ the executable code aspects of DBC (or Ada
run time checks) in hard real time systems with constrained
resources.  

  The other issue is that in the Ariane 5 case, the 
methodology that was in place (system requirements review and
software requirements specification), was not followed 
adequately.  To quote the inquiry report once more: 

  "the overriding means of preventing failures are the reviews 
   which are an integral part of the design and qualification 
   process, and which are carried out at all levels and involve 
   all major partners in the project (as well as external 
   experts)"

The Ariane 4 IRS software as-is reuse should not have made it
by such reviews.  Please read Ken's rebuttal paper:

  http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

  My reading of it does not indicate a general "critising DBC"
but rather it summerizes:

  "In the specific case of the Ariane IRS design fault, there
  is not clear and compelling evidence that DBC/Eiffel 
  assertions were likely to have uncovered the fault prior to 
  operational use, either through their documentation, test, 
  or execution value. Furthermore, alternative means were 
  available to the Ariane team to isolate the particular 
  fault, even without the use of DBC/Eiffel. Therefore, 
  although there may be a compelling claim to use DBC/Eiffel 
  in real-time safety-critical systems, the Ariane case 
  (and the Eiffel paper describing this case) does not 
  support such a claim."

  My complaint is against the claim in the Eiffel paper:

  "Does this mean that the [Ariane 5] 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..."
     ^^^^^^^^^^^^

    I say, IMO, probably no for the Ariane 5 case.  But I
think it is a "good thing" to use assertions and/or a DBC
methodology whenever practical.  Unfortunately, IME, it is
often not practical for resource constrained hard real time
systems.  
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Robert S. White wrote:
>   The other issue is that in the Ariane 5 case, the
> methodology that was in place (system requirements review and
> software requirements specification), was not followed
> adequately.  To quote the inquiry report once more:
...
>   My complaint is against the claim in the Eiffel paper:
> 
>   "Does this mean that the [Ariane 5] 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..."
>      ^^^^^^^^^^^^
> 
>     I say, IMO, probably no for the Ariane 5 case.

I'd even tolerate the "probably yes," if it weren't
explicitly stated that DBC is the ONLY method that would
probably have avoided the crash.

No discussion about whether DBC would have helped is relevant
to my point.  I concede that DBC is one method that would
have helped.

I'll say that again:

    I CONCEDE THAT DBC WOULD PROBABLY HAVE HELPED, IF ONLY
    BECAUSE IT ISN'T DBC WITHOUT REVIEWS AND TEST.

But the paper says that ONLY DBC would have helped, as I'll
show below.  If the authors had said "Yes, the claim was too
strong, sorry," a lot of us would have shut up and gone away.

Co-author Jean-Marc Jezequel has said that this does not
characterize what the paper was MEANT to say.  I have
little dispute with what he says they MEANT to say[1]:

  Let's finally sum up what I perceive as the most important
  claims in this paper:
  - reusing a component without checking its full specification
    is dangerous, which means that simple minded CORBA-like
    approaches at building components for mission-critical
    software are doomed.
  - using design by contract is an interesting way to specify the
    behavior of a component
  - at least in the case of Ariane 501, simple assertions (a la
    Eiffel and other languages) would have been expressive enough
    to specify the fatal hidden assumption.

But the paper DOES state explicitly that DBC is the ONLY method
that would have avoided the crash, and that existing methods were
applied but did not succeed.

Following are my reasons for stating that the paper says this.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
THE PAPER CLAIMS THAT ARIANE 5 APPLIED ALL RELEVANT EXISTING METHODS

At the very least it strongly implies this.

From the paper:
    The ESA's software people knew what they were doing and applied
    widely accepted industry practices.

No, the project made an explicit decision to NOT apply widely
accepted industry practices.

I have yet to see any support for this assertion: not in the Eiffel
paper, not in the ESA report, not in the net traffic.


From the paper:
    Is it a testing error?  Not really.  ...  But if one can test more
    one cannot test all.  Testing, we all know, can show the presence
    of errors, not their absence.

This implies that the error in question would not likely have been
found through normal testing.  Yet it is, in fact, one that would
have blown out a normal test scenario the first time they tried it.
The addition of DBC would have made no more difference than would
the addition of paper hats.  There may indeed be errors that cannot
be found through testing, and that DBC would find, but this is NOT
demonstrated by the Ariane 5 case.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
THE PAPER CLAIMS THAT ONLY DBC WOULD HAVE PREVENTED THIS ERROR

The concluding section, labelled "The lesson for every software
developer," is clearly meant to state what the Ariane 5 crash shows.
It states:

    To attempt to reuse software without Eiffel-like assertions is
    to invite failures of potentially disastrous consequences.
    ...
    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.

This says that, if a reused component has not been analyzed with
DBC, you cannot trust it, and you are inviting failure.  No other
method is sufficient, by this statement.


From the paper:
    Reuse without a contract is sheer folly.

Does this state that Ariane 5 would have crashed, no matter what
other methods were used, unless DBC were also used?  In context,
yes.  It's from the conclusions section, "The lesson for every
software developer."  Surely this is meant to be the lesson of the
Ariane 5 crash.  Surely "contract" in this context is intended to
refer specifically to a Design By Contract artifact.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[1] I'd dispute his first point if "full specification" is limited
    to pre/post conditions and invariants.  In some cases these are
    too little, in others they may not be needed.  However, it's
    certainly failure-prone to reuse components without reviewing
    their specs and designs.  I know too little about CORBA to have
    an opinion on its (in)sufficiency.

Sam Mize

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Samuel Mize wrote:

> Co-author Jean-Marc Jezequel has said that this does not
> characterize what the paper was MEANT to say.  I have
> little dispute with what he says they MEANT to say[1]:
...
> [1] I'd dispute his first point if ...

This footnote looks like a reference.  I apologize for the
inclarity.

I should have referenced the text.  According to Deja News,
Mr. Jezequel posted this statement on 1997/03/18 to
comp.lang.eiffel, comp.object, comp.software-eng,
comp.programming.threads, comp.lang.ada, and comp.lang.java.tech.

Sam Mize

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Robert S. White wrote:
> 
> The Ariane 4 IRS software as-is reuse should not have made it
> by such reviews.  Please read Ken's rebuttal paper:
> 
>   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/
> 
>   My reading of it does not indicate a general "critising DBC"
> but rather it summerizes:
> 
>   "In the specific case of the Ariane IRS design fault, there
>   is not clear and compelling evidence that DBC/Eiffel
>   assertions were likely to have uncovered the fault prior to
>   operational use, either through their documentation, test,
>   or execution value. Furthermore, alternative means were
>   available to the Ariane team to isolate the particular
>   fault, even without the use of DBC/Eiffel. Therefore,
>   although there may be a compelling claim to use DBC/Eiffel
>   in real-time safety-critical systems, the Ariane case
>   (and the Eiffel paper describing this case) does not
>   support such a claim."

In addition, it states in section 6:

"It would not be appropriate to use the criticisms here to say
in the general case that assertions have no value, anywhere
("casuistry"), but this criticism does not attempt to do this.
It focuses on the specific claim in the Eiffel paper in the
context of the Ariane IRS fault.... 

"Several Eiffel advocates will attest that they like the use of
Eiffel for their domain. Eiffel may be very useful in some domains,
however Ariane is a real-time embedded safety-critical system and
has unique properties (as described above). Again, this is a specific,
not a general, criticism of DBC/Eiffel."

Perhaps my paper is so boring that no one made it to this
section :)

Re: Critique of Ariane 5 paper (finally!)

[Nick Leaton]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8512 bytes --]


Ken Garlington wrote:
> 
> Nick Leaton wrote:
> >
> > Let us say for the moment that in some circumstances DBC helps.
> > For those that have been critising DBC, since DBC is optional, and is an
> > addition to the current methodology I think the only valid criticism one
> > make, is if you can find a situation where DBC causes a problem.
> >
> > That is, where does DBC screw up, and the current methodologies do not.
> 
> See my Ariane paper for some examples of such information:
> 
>   http://www.flash.net/~kennieg/ariane.html#s3.1.6

QUOTE -----------------------------------------------------------
3.1.6 Adverse effects of documenting assertions

     There is a line of reasoning that says, "Even if DBC/assertions
would have been of minimal use, why not include them anyway just in case
they do
     some good?" Such a statement assumes there are no adverse impacts
to including assertions in code for documentation purposes. However,
there
     are always adverse effects to including additional code: 

         As with any other project, there are management pressures to
meet cost and schedule drivers. Additional effort, therefore, is
discouraged
         unless justified.

         More importantly, all projects have finite time and other
resources available. Time spent on writing and analyzing assertions is
time not
         spent elsewhere. If the work that is not performed as a result
would have been more valuable (in terms of its effect on the safety and
         integrity of the system) than the time spent with assertions,
then the resulting system may be less safe. 

     There is a growing consensus in the safety-critical software field
that simpler software tends to be safer software [21]. With this
philosophy,
     additional code such as assertions should only be added where there
is a clear benefit to the overall safety of the particular system being
     developed. 
END QUOTE --------------------------------------------------------

1) Additional effort.
There is plenty of evidence that the cost of finding and fixing a bug
early in the development process is much cheaper that fixing it later.
Now *IF* DBC as a methodology produces earlier detection of faults, then
this 'additional effort' is justified, as it is effort early in the
development process. I believe this to be the case from practical
experience. Developing code last week I detected errors in my code very
early, even though the fault would have only shown itself in an
exception. I had an invariant that made sure I had an error handler in a
class. It broke as soon as I tried to construct the class, it didn't
wait until I tried to generate an error, all because I hadn't set the
handler up. That combined with permantant testing of assertions has the
effect of producing less effort.

2) Time spent else where.
Is this the case? Some of it may be, but I believe if you cannot be
rigourous about what your software is trying to do, by writing
assertions, then you are unlikely to produce a quality system. The
effect of writing assertions overlaps with the design process. It is not
wasted time, it just comes under a different heading. If your design
process listed the assertions in the specification, would implementing
them be a waste of effort?

3) Simple software. 
You bet. The simpler the better. Occams Razor rules. Now here there is a
split between DBC a la Eiffel and DBC, say in C++. In Eiffel it is
simple. In C++ it is hard, particularly with inheritance of assertions.
One common theme from Eiffel practitioners is their support for DBC.
Why? They are simple to write. Prior to using Eiffel I had read about
the language. I was extremely sceptical about assertions because in my
experience with C++ and C++ programmers, no one writes them, mainly
because it is hassle. Take away the hassle and people will write them
because of the benefits.



>   http://www.flash.net/~kennieg/ariane.html#s3.2.2

QUOTE --------------------------------------------------------
3.2.2 Adverse effects of testing with assertions

     Assume for a moment that the proper testing environment and data
had been available. Putting aside for the moment the question as to
whether
     assertions would have been necessary to detect the fault (see
section 4.2), are there any disadvantages to using assertions during
testing, then
     disabling them for the operational system? In the author's
experience, there are some concerns about using this approach for
safety-critical
     systems: 

         The addition of code at the object level obviously affects the
time it takes for an object to complete execution. Particularly for
real-time
         systems (such as the Ariane IRS), differences in timing between
the system being tested and the operational system may cause timing
         faults, such as race conditions or deadlock, to go undetected.
Such timing faults are serious failures in real-time systems, and a test
which
         is hindered from detected them loses some of its effectiveness.

         In addition, the differences in object code between the tested
and operational systems raise the issue of errors in the object code for
the
         operational system. Such errors are most likely to occur due to
an error in the compilation environment, although it is possible that
other
         factors, such as human error (e.g. specifying the wrong version
of a file when the code is recompiled) can be involved. For example, the
         author has documented cases where Ada compilers generate the
correct code when exceptions are not suppressed, but generate
         incorrect code (beyond the language's definition of
"erroneous") when they are suppressed. This is not entirely unexpected;
given the
         number of user-selectable options present with most compilation
environments, it is difficult if not impossible to perform adequate
toolset
         testing over all combinations of options. Nothing in the Eiffel
paper indicates that Eiffel compilers are any better (or worse) than
other
         compilers in this area. Although this is a fault of the
implementation, not the language or methodology, it is nonetheless a
practical limitation
         for safety-critical systems, where one object code error can
have devastating results. 

     One possible approach to resolving this issue is to completely test
the system twice; once with assertions on and another time with
assertions
     suppressed. However, the adverse factors described in section 3.1.6
then come into play: By adding to the test time in this manner, other
useful
     test techniques (which might have greater value) are not performed.
Generally, it is difficult to completely test such systems once, never
mind
     twice! This effect is worse for safety-critical systems that
perform object-code branch coverage testing, since this testing is
completely
     invalidated when the object code changes [25]. 

     Overall, there are significant limitations to using this technique
for safety-critical systems, and in particular real-time systems such as
the Ariane
     5 IRS. 

END QUOTE --------------------------------------------------------

Assertions affect timing in safety critical systems.

Firstly it depends on the implementation. It is easy to envisage a
system where the assertions are redundantly executed. But you would only
want to do that if you were running with faulty software ?!*^�%

I also find it worrying that systems are being used for safety critical
apps where there is the possibility of a race or deadlock to occur. 

Compilation problems.
These can occur in any system as you are aware. From discussions with
some of the people involved in writting Eiffel compilers, the enabling,
disabling of assertions has a very trivial implementation, which is very
unlikely to go wrong. It has also be extensively tested in the field by
end users.
Do you trust your compiler? If not, you shouldn't be writing safety
critical software with it. Period.

Next I find some of the logic of your arguments here very weak.
Paraphrasing. We have trouble testing safety critical systems, but we
will use them anyway. Hmmm.


>   http://www.flash.net/~kennieg/ariane.html#s3.3
> 
> There are approaches that can avoid such costs, particularly those of
> 3.2.2 and 3.3 (by not requiring object code modification). 3.1.6 can
> be mitigated through the use of techniques that minimize cost (e.g.
> automated structural testing analysis).
> 
> >
> > --
> >
> > Nick

-- 

Nick

Re: Design By Contract

[Ted Velkoff]

W. Wesley Groleau x4923 wrote:
> 
> Question for anyone who _really_ knows both Eiffel and Ada:
> Suppose Ada added Eiffel assertions and Eiffel added separate
> compilation of specs.  Or even some sort of automated control that
> prevented changing contract without special privilege.
> 
> What remaining feature of either language (or both) would be a
> significant advantage over the other and why?
> 

In no particular order I offer my view of the remaining differences.  To 
the best of my ability I've responded with reason and judgement :-)

Concurrency.
	Ada's tasking is certainly more mature and tested in fielded 
products.  There has been a lot of research done into concurrency in Ada 
that benefited Ada95.
	I personally find the SCOOP approach to concurrency proposed for 
Eiffel to be quite elegant from the standpoint of the ordinary 
programmer building a concurrent system.  I think the jury's still out 
on how well it can be implemented.  There are some important issues 
(like priority inversion, rate-monotonic scheduling, etc., among many 
others) that need to be addressed in order to be applied to the 
some of the kinds of systems that have been done in Ada.

Constrained genericity.
	Constrained genericity is achieved in Ada typically by adding 
generic function or procedure parameters to the parameter list.  
Depending on the generic type, that list of parameters could be long.
	I think the Eiffel approach, which says an actual parameter must 
conform to (i.e. inherit from) some class, is simple and powerful, and 
typically results in shorter parameter lists.

Multiple inheritance.
	I've read the section on multiple inheritance in the Ada95 
Rationale several times and I confess I have never been able to 
understand the 2nd or 3rd examples.  At the very least, it appears that 
just emulating multiple inheritance in Ada95 is hard.
	Of course the religious question is whether you believe in MI or 
not.  After not being sure for about a year, I've come to believe it is 
extremely useful.  I think Bertrand Meyer is correct in saying that MI 
is not bad as long as it is implemented properly.  Using MI in Eiffel is 
really just no big deal.

Dynamic binding.
	Someone please correct me if I'm wrong on this one, but I think 
in Ada95, the programmer has to designate whether dynamic binding can be 
applied by making a type "classwide" with 'Class.  I think this is 
comparable to C++ "virtual", but I think I read that the Ada compiler is 
supposed to figure out which classwide calls are actually static in an 
executable.  The chief objection (if I have understood the Ada mechanism 
correctly) might be that one might forget to make a type classwide that 
a descendant would need to override, and require a change to the code.
	In Eiffel, dynamic binding is the default.  The programmer has 
to do something special ("frozen") to make it impossible for descendants 
to redefine.
	
Garbage collection.
	There are many applications being done in Ada for which garbage 
collection is not appropriate (hard real-time, etc.).  I suspect that 
there are many more applications being done in Ada that could benefit 
from garbage collection.
	Eiffel is of course garbage collected.  There are also library 
facilities for fine-grained control during execution.

Exception handling.
	Ada is fairly permissive with exceptions.  (Meyer has written 
about this in several places.)  The bad things that I have done and seen 
done in Ada are to use exceptions as gotos, and sweep problems under the 
rug.
	Eiffel is much more restrictive about what can be done in 
response to exceptions.  It significantly reduces the chances of 
programmers doing these sorts of things.

Tool environments.
	Articles have appeared in Ada Letters that questioned the wisdom 
of incorporating inheritance into Ada95, based on the fact that 
comprehension of a class interface requires manually finding and 
traversing the set of ancestors.  This problem is of course not unique 
to Ada.  As far as I know, Eiffel environments are the only I know of 
that support class flattening (i.e. generating the union of all features 
of all ancestors).  They also support push-button access to the list of 
clients, suppliers, ancestors, descendants.  I don't know how many times 
in other languages (including Ada) I have really needed to find out 
"who's calling this?" and had nothing better at my disposal than grep.  
Of course these are not language issues - I'd love to see vendors of Ada 
products add these kinds of capabilities.

Child packages.
	At a minimum, the rules about child packages are complicated.  
I'm personally unconvinced by the examples in the Ada95 Rationale for 
their use.  In particular, the example of complex numbers seems to be 
more properly addressed by inheritance (i.e. tagged types).  I would 
worry that programmers using that as a guide would attempt to solve many 
problems with child packages that should use inheritance instead.

Pointers to functions, aliases.
	I sort of got the heeby-jeebies when I saw these introduced into 
Ada95.  They didn't appear any easier or safer to use than their 
counterparts in C/C++.  In Ada83, you could sort of see the argument for 
subprogram pointers, but once inheritance and abstract subprograms were 
introduced, they seemed out of context to me.
	Eiffel doesn't have these things since they are tricky to use 
and jeopardize reliability.

-- Ted Velkoff

Re: Design By Contract

[Darren New]

In article <34058808.3BF@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>Paul Johnson wrote:
>> Now in my code I have something like:
>> 
>>    a: A;
>>    b: B;
>
>Is this legal Eiffel?  If so, put case insensitivity on the list of
>Ada's advantages.
>
>Unless Eiffel demands upper case for types/classes and lower case
>for variables/constants.  In that case, it's even, i.e., the 
>distinction introduces some benefits but also some problems.

Uh, no. That's not the point.

In Eiffel, there's certain syntactic places the name of a class can appear,
and certain syntactic places the name of a variable can appear, and the
two don't overlap.  Hence, the case distinction is irrelevant.

This is like saying in C

struct x { struct x * next; int data; }
struct x next;
[...]
next = next->next;

Now, granted, in this case it's probably bad style, but there's no confusion
that the first two "next" references are to the variable and the third is
to the structure member.

Same idea in the Eiffel code.

Re: Design By Contract

[Patrick Doyle]

In article <5u3c6v$gtf$2@miranda.gmrc.gecm.com>,
Paul Johnson <paul.johnson@gecm.com> wrote:
>In article <3403C44F.2424@erols.com>, velkoff@erols.com says...
>
>[In the middle of an otherwise good posting]
>
>>        In Eiffel, dynamic binding is the default.  The programmer has 
>>to do something special ("frozen") to make it impossible for descendants 
>>to redefine.
>
>I've seen this mistake made a few times around the net.  The assumption is
>that "frozen" was introduced as a sort of "anti-virtual", or at least that
>it has this effect.

[Discussion of difference between dynamicity and redefinability]

>The correct answer is "2".  The dynamic binding still happens.  The only
>effect of "frozen" is that if I create a new descendant of "B", I cannot
>redefine "foo" in it.
>
>Dynamic binding and "frozen" are orthogonal issues.

  Now, have a look at the quote you took, and tell me how it
contradicts this.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[Joachim Durchholz]

Patrick Doyle wrote:
> >Dynamic binding and "frozen" are orthogonal issues.
> 
>   Now, have a look at the quote you took, and tell me how it
> contradicts this.

Nonvirtual C++ functions and frozen Eiffel routines are not the same.

1) Even a frozen routine can be polymorphic - it may itself override an
inherited routine. (This is not an issue for the frozen features
declared in ANY, PLATFORM or GENERAL.)
2) There is no way in Eiffel to achieve the effect of C++ nonvirtual
member functions. If you have a routine
  blah (x: A_CLASS) is
  do
    x.do_something
  end
the standard C++ policy (nonvirtual routine) would be to always call
A_CLASS.do_something, regardless of wether the parameter passed in for x
is of that type or of a descendant. In Eiffel, the decision which
routine to call will always be based on the run-time type of x, *never*
on the declared type along.
(Of course, if do_something is frozen in A_CLASS, no polymorphism is
possible, so the compiler should optimize this to a static call. But
that's the same as when the compiler determines that only A_CLASS
objects will be passed for x in the given program.)

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Design By Contract

[Patrick Doyle]

In article <34108452.BAF03BA5@munich.netsurf.de>,
Joachim Durchholz  <joachim.durchholz@munich.netsurf.de> wrote:
>Patrick Doyle wrote:
>> >Dynamic binding and "frozen" are orthogonal issues.
>> 
>>   Now, have a look at the quote you took, and tell me how it
>> contradicts this.
>
>Nonvirtual C++ functions and frozen Eiffel routines are not the same.

  I don't disagree with this.  My point is that what you quoted
did not claim they were the same.  However, you've removed the quote
and my mail reader no longer has the original, so I can't explain
further.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[W. Wesley Groleau x4923]

Jon S Anthony wrote:
> 
> In article <3403C44F.2424@erols.com> Ted Velkoff <velkoff@erols.com> writes:
> 
> > Constrained genericity.
> >       Constrained genericity is achieved in Ada typically by adding
> > generic function or procedure parameters to the parameter list.
> > Depending on the generic type, that list of parameters could be long.
> >       I think the Eiffel approach, which says an actual parameter must
> > conform to (i.e. inherit from) some class, is simple and powerful, and
> > typically results in shorter parameter lists.
> 
> That's not quite right.  The Ada approach basically subsumes the
> Eiffel approach: an actual must conform/inherit from some class or you
> can use an approach sort of like what you mention.  Also, in the
> latter case, the parameter lists can be captured in a signature
> package which can then be passed as a single parameter to another
> generic.
> 
> >       Of course the religious question is whether you believe in MI or
> > not.
> 
> Right.
> 
> >  After not being sure for about a year, I've come to believe it is
> > extremely useful.  I think Bertrand Meyer is correct in saying that MI
> 
> Somewhat interestingly, I (and some others here) went the other way
> 'round and now consider MI to be (generally speaking) poor modeling.
> 
> > is not bad as long as it is implemented properly.  Using MI in
> > Eiffel is really just no big deal.
> 
> It makes it at least "reasonable" - but it does not address the
> modeling issue.
> 
> > Dynamic binding.
> >       Someone please correct me if I'm wrong on this one, but I think
> > in Ada95, the programmer has to designate whether dynamic binding can be
> > applied by making a type "classwide" with 'Class.  I think this is
> 
> A dynamic binding can be applied to primitive operations of "tagged"
> types.  _Whether_ any given _invocation_ of such an operation will be
> so treated requires that the actual involved be classwide.  So, all
> primitive ops of tagged types are dispatchable, but if you can control
> for any given call instance whether you really want that to happen
> 
> > comparable to C++ "virtual", but I think I read that the Ada compiler is
> 
> Not like C++ "virtual".  In C++ only operations tagged with "virtual"
> can be dispatching and this tagging happens at the point they are
> _declared_.  In Ada, all primitive ops of tagged types are
> dispatching.
> 
> > executable.  The chief objection (if I have understood the Ada mechanism
> > correctly) might be that one might forget to make a type classwide that
> > a descendant would need to override, and require a change to the code.
> 
> This is indeed a problem with C++ "virtual" but has nothing to do with
> Ada.
> 
> > Garbage collection.
> >       There are many applications being done in Ada for which garbage
> > collection is not appropriate (hard real-time, etc.).  I suspect that
> > there are many more applications being done in Ada that could benefit
> > from garbage collection.
> 
> Absolutely.
> 
> >       Eiffel is of course garbage collected.  There are also library
> > facilities for fine-grained control during execution.
> 
> Right.
> 
> > Exception handling.
> 
> This actually seems to be another religious issue.
> 
> > to Ada.  As far as I know, Eiffel environments are the only I know of
> > that support class flattening (i.e. generating the union of all features
> > of all ancestors).
> 
> I seem to recall some freeware stuff that can do this for any language
> with class based heirarchy.  If anyone actually cares, I think I can
> dig this up...
> 
> >  They also support push-button access to the list of clients,
> > suppliers, ancestors, descendants.  I don't know how many times in
> > other languages (including Ada) I have really needed to find out
> > "who's calling this?" and had nothing better at my disposal than
> > grep.
> 
> Such tools certainly do exist.  Emacs ada-mode does much of this.
> Other environments pretty much do it all and then some.
> 
> > more properly addressed by inheritance (i.e. tagged types).  I would
> > worry that programmers using that as a guide would attempt to solve many
> > problems with child packages that should use inheritance instead.
> 
> Or vice-versa.  I'm no longer a big fan of class-based inheritance.
> It is useful and has its place.  But like anything else - it is a poor
> choice for "universal" application.
> 
> > Pointers to functions, aliases.
> >       I sort of got the heeby-jeebies when I saw these introduced 
> > into Ada95.  They didn't appear any easier or safer to use than 
> > their counterparts in C/C++.  In Ada83, you could sort of see the 
> > argument for subprogram pointers, but once inheritance and abstract 
> > subprograms were introduced, they seemed out of context to me.
> 
> These things do have their ups and downs.  To be fair, the way they
> are done in Ada, probably the "worst" thing about them is they look
> "ugly" - makes it look like you are cheating or up to something
> nefarious.  Note that no matter what, you kind of need subprogram
> pointers to be a "good citizen" in today's C dominated world.

They are _certainly_ safer than in C.  Ada ensures conformance
of parameter profiles and being in scope.  It is true (as evidenced
by the number of "why doesn't this work?" posts on the subject) that
they are not easier to use than in C, but that is a side-effect of 
the safety rules.

Inheritance, abstract subprograms, generic subprog params can
substitute for subprog pointers, but not sometimes in a less
readable and/or less efficient way, and sometimes not at all
(as with the X11 & C callback paradigm).

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Design By Contract

[Don Harrison]

Jon S Anthony wrote:

:OTOH, Ada has no system validity problems.

System validity, in its broadest sense, means that all usage of entities 
(variables) in a system is legal for all possible objects/values that 
can become attached (assigned) to them at runtime. This definition includes, 
but is not limited to, what is traditionally regarded as polymorphic usage. 

While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other 
usage. See Deja News for details.

So, your claim that Ada doesn't have system validity problems is false.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Jon S Anthony]

In article <EFx966.8LB@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> System validity, in its broadest sense, means that all usage of entities 

Well, you can define it anyway you wish, I suppose, but I was simply
refering to its "traditional" usage vis-a-vis Eiffel.

> While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other 
> usage. See Deja News for details.
> 
> So, your claim that Ada doesn't have system validity problems is false.

As I recall, that scenario required the _concious_ and _explicit_
choice to violate certain aspects via Unchecked_Conversion.  Not at
all the same as the concealed land mines of Eiffel.  But, I'm not
going to say these are somehow ultra-bad or something.  In practice
they are probably not that big of a deal if you are aware and careful
to avoid the situations.  Besides, you snipped the one of two smileys
I had in there...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Don Harrison]

Jon S Anthony wrote:

:In article <EFx966.8LB@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
:
:> System validity, in its broadest sense, means that all usage of entities 
:
:Well, you can define it anyway you wish, I suppose, but I was simply
:refering to its "traditional" usage vis-a-vis Eiffel.

Sure.

:> While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other 
:> usage. See Deja News for details.
:> 
:> So, your claim that Ada doesn't have system validity problems is false.
:
:As I recall, that scenario required the _concious_ and _explicit_
:choice to violate certain aspects via Unchecked_Conversion.  

No, I'm not referring to Unchecked_Conversion. As we both know, all bets are 
off when you choose to do naughty things.

I recall we agreed that neither Ada nor Eiffel stopped you statically from 
trying to attach an out-of-range value at runtime - for Ada, to a subtype;
for Eiffel to a precondition-constrained type. 

However, I recall Norman Cohen (I think) volunteering a hole in Ada's type
system - don't remember the details, though. 

BTW, where is Norm these days? Haven't seen him in c.l.a. lately.

:Not at all the same as the concealed land mines of Eiffel.  But, I'm not
:going to say these are somehow ultra-bad or something.  In practice
:they are probably not that big of a deal if you are aware and careful
:to avoid the situations.  

Quite true. Essentialy, being able to break polymorphism isn't any worse
than the uncertainty of not knowing whether a precondition will always be 
satisfied. It can justifiably be regarded as a variant of just that. There's
no question, of course, that it would be preferable to exclude such 
errors statically, rather than having to deal with them dynamically.

:Besides, you snipped the one of two smileys
:I had in there...

True.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Jon S Anthony]

In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

>   - Strict enforcement of encapsulation while maximising visibility. Eiffel 
>     offers a look-but-don't-touch view of object attributes. In Ada83,
>     an attribute and its type has to be declared in the visible interface in 
>     order for clients to see it's structure but then they can also update it 
>     directly. If you declare its type as private, clients can't update it 
>     directly but neither can they see its structure.

Isn't that exactly the point?  Why should a client be able to see the
actual structure, aka implementation????

>   - Simplicity which enables developers to focus on designing rather than
>     trying to remember language rules. A simplistic macroscopic comparison 
>     of Eiffel and Ada based on the number of validity rules suggests that
>     Eiffel is about 50 times simpler than Ada. 

IMO, this is obviously one of those "yes it is, no it isn't" sort of
things.  It would be very difficult to get a _consistent_ objective
metric for this.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Don Harrison]

Jon S Anthony wrote:

:In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
:
:>   - Strict enforcement of encapsulation while maximising visibility. Eiffel 
:>     offers a look-but-don't-touch view of object attributes. In Ada83,
:>     an attribute and its type has to be declared in the visible interface in 
:>     order for clients to see it's structure but then they can also update it 
:>     directly. If you declare its type as private, clients can't update it 
:>     directly but neither can they see its structure.
:
:Isn't that exactly the point?  Why should a client be able to see the
:actual structure, aka implementation????

No, the point is that there is no need to hide the structure of an attribute
so long as it's read-only (look-but-don't-touch). These semantics allow you 
to query components of visible objects directly:

  a.SOME_TYPE
  ...
  if a.y > 0 then
    x := a.y
  end

but prevent you from updating them directly (which would break encapsulation):

  a.y := x        -- Illegal

[You can update them *indirectly* by calling an operation in the object:

  a.set_y (x)]


To get similar read-only semantics in Ada, you have to declare the attribute 
in the package body (hiding it) and return it via an exported function (which
can't have the same name):

  the_a: SOME_TYPE
  ...
  function a return SOME_TYPE is
  begin
    return the_a;
  end;

I prefer the Eiffel model because:

  - It's simple and direct.
  - It doesn't clutter the spec and body with functions.
  - It doesn't force you to invent multiple identifiers (one of which has 
    a contrived name: "the_a" above).


IMO, the other possibilities for attributes in Ada are unattractive because
they are either too permissive (look-and-touch - attributes declared in the 
visible part of the spec) or too restrictive (don't-look-don't touch - 
private attributes).

BTW, someone with a sense of humour may enjoy BM's discussion of Ada private 
types (OOSC-2, 33.4 - Hiding the Representation: The Private Story. P.1085-1087).

[...]


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Jon S Anthony]

In article <EFnoJv.1vx@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> :Isn't that exactly the point?  Why should a client be able to see the
> :actual structure, aka implementation????
> 
> No, the point is that there is no need to hide the structure of an attribute
> so long as it's read-only (look-but-don't-touch). These semantics allow you 
> to query components of visible objects directly:

I'm not convinced that is sufficient.  Knowing the structure can lead
one into writing things that still depend on it (efficiency hacks come
quickly to mind).

> I prefer the Eiffel model because:
> 
>   - It's simple and direct.
>   - It doesn't clutter the spec and body with functions.
>   - It doesn't force you to invent multiple identifiers (one of which has 
>     a contrived name: "the_a" above).

Fine.  Of course, all of these are simply _subjective_
characterizations.  If that is what floats your boat - go for it.

> IMO, the other possibilities for attributes in Ada are unattractive
> because they are either too permissive (look-and-touch - attributes
> declared in the visible part of the spec) or too restrictive
> (don't-look-don't touch - private attributes).

Again, this is simply personal perspective.  It may mean a lot to you,
but you should be aware that this subjective stuff ("unattractive"
"too permissive" "too restrictive") is just opinion and preference and
that others may well view _your_ preferences as "unattractive", "too
permissive" and "too restrictive".  There just is no consistent
objective criteria here.  And no amount of saying it's so will make it
so.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Patrick Doyle]

In article <JSA.97Aug30145058@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>Generally speaking, opinion (mine included) is irrelevant and just
>leads to the complete waste of bandwidth these sorts of silly threads
>suck up.

  Ok, if you want to turn this place into an online technical
manual, fine.  I think I'll keep reading others' opinions ("irrelevant"
and "waste of bandwidth" as they may be) just in case I might
actually learn something.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[Don Harrison]

Jon S Anthony wrote:

:In article <EFnoJv.1vx@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
:
:> :Isn't that exactly the point?  Why should a client be able to see the
:> :actual structure, aka implementation????
:> 
:> No, the point is that there is no need to hide the structure of an attribute
:> so long as it's read-only (look-but-don't-touch). These semantics allow you 
:> to query components of visible objects directly:
:
:I'm not convinced that is sufficient.  Knowing the structure can lead
:one into writing things that still depend on it (efficiency hacks come
:quickly to mind).

The thing is, though, that the designer of the supplier class *intends* the
client to see the structure of attributes in just the same way as the author
of an Ada interface *intends* clients to see the structure of a value returned
by a function.

Exporting happens on a need-to-know basis. If clients need attributes for 
any purpose (including efficiency tuning), then the supplier exports them. 
If they don't, then the supplier keeps them hidden. Note that in the extreme 
case of an attribute whose underlying class exports none of its attributes, 
you have the equivalent to an Ada private attribute. That is, the Ada

package Some_Module is
  type My_type is tagged private;
  ...                     -- exported operations
  No_structure : My_type;
private
  type My_type is tagged record
    ...                   -- hidden attributes
  end record;
end;

is roughly equivalent to the Eiffel

class MY_CLASS
  feature
    ...                   -- exported operations
  feature {NONE}
    ...                   -- hidden attributes
end

class SOME_CLASS
  feature
    no_structure : MY_CLASS
end

So, if a supplier really needs to restrict what clients can see, for whatever 
reason, they're able to.

However, the good thing about Eiffel is that it gives designers the flexibility
of exposing as much or as little of an object's structure, in contrast with 
with Ada's you-see-it-all or you-see-nothing export policy.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Jon S Anthony]

In article <EFuuJK.GKu@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> So, if a supplier really needs to restrict what clients can see, for
> whatever reason, they're able to.

Agreed.  Never claimed otherwise.


> However, the good thing about Eiffel is that it gives designers the
> flexibility of exposing as much or as little of an object's
> structure, in contrast with with Ada's you-see-it-all or
> you-see-nothing export policy.

First, whether or not this is "good" depends on many things.

Second, you can play the same game in Ada anyway:

package P is

    type T is limited private;

    type S1 is tagged record
        ...
    end record;

    type S2 is ... end record;

    type Whatever is private;

    function Op1 (X : T) return S1; -- Expose S1 substructure

    function Op2 (X : T) return S2; -- Expose S2 substructure

    function Op3 (X : T) return Whatever; -- Don't expose this bit

...
private
...
end P;


Also, even here, you it is possible to get at the remaining hidden
structure if it is in the private portion with child packages.  So,
per usual, at the end of the day there really isn't enough overall
differences on which to waste energy...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Don Harrison]

Jon S Anthony wrote:

:In article <EFuuJK.GKu@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

[..]

:> However, the good thing about Eiffel is that it gives designers the
:> flexibility of exposing as much or as little of an object's
:> structure, in contrast with with Ada's you-see-it-all or
:> you-see-nothing export policy.

I realised after writing this that you can export as much or as little as you
like in Ada. In terms of individual attributes, you can do this by supplying 
a function if you want to export an attribute and by not supplying one if you 
want to hide one.

:Second, you can play the same game in Ada anyway:

Agree.

:package P is
:
:    type T is limited private;
:
:    type S1 is tagged record
:        ...
:    end record;
:
:    type S2 is ... end record;
:
:    type Whatever is private;
:
:    function Op1 (X : T) return S1; -- Expose S1 substructure
:
:    function Op2 (X : T) return S2; -- Expose S2 substructure
:
:    function Op3 (X : T) return Whatever; -- Don't expose this bit
:
:....
:private
:....
:end P;

Presumably, T here is composed of S1 and S2 among other things.
I agree it gives similar functionality to Eiffel.

:Also, even here, you it is possible to get at the remaining hidden
:structure if it is in the private portion with child packages.  

Agree.

BTW, I've just re-read the stuff on child packages (public and private) 
in the Ada95 Rationale. It's making more sense and I can see a couple of
places in our recently completed simulation where private child packages 
would have been useful. They would have been handy for decomposing a couple 
of large abstractions into components while not exposing the internal 
interfaces to outsiders.

I still prefer the Eiffel mechanisms for a couple reasons:

  a) Simpler
  b) Views may be directed to specific clients

but it does seem to hold together pretty well. Also, it appears you can 
acheive comparable export granualarity in Ada and Eiffel.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Paul Johnson]

In article <JSA.97Sep3201329@alexandria.organon.com>, 
jsa@alexandria.organon.com says...

>I believe that it is possible to get a reasonable level of this
>awareness without such "steeping" - as long as you are very careful
>about not confusing explicit _features_ with the _expressivity_ of the
>languages.  One may have a specific feature for capability X while the
>other achieves X by a nice little combination or particular
>utilization of some other features or constructs.  And, understanding
>this is really the key to rational and (more or less) objective
>language comparisons.

These are wise words.  On the other hand I would hold that a language with
direct support for something is better for that thing than a language which
requires some idiom.

For example Eiffel has direct support for multiple inheritance (MI).  Ada
requires you to play games with generic parameters in order to achieve
the same effect.

Here are the reasons I dislike idiomatic programming:

1: Its harder to read.  The reader must "reverse engineer" the design
   of the system by looking at the idiom and recognising it.  This
   generally requires that the reader be familiar with the idiom in
   question.  I recall being totally flumoxed when I was learning
   assembler and came across my first "JMP" instruction at the end of
   a routine.  Later of course, I learned the trick and would now understand
   such code.

2: Its harder to optimise.  I suspect that MI in Ada provides another
   good example here.  In Eiffel the various jump tables needed for MI
   can be optimised, for example by eliminating duplication.  As far as
   I can see you can't do that in Ada because the compiler does not have
   the necessary information about what the programmer is doing.

(BTW, I would be very interested in more information about that last point).

Of course, this on its own would be an argument for a very large and
complex language with specific support for just about everything.  This
would be a bad thing: simplicity in language design is a Good Thing.  OTOH
learning an idiom is not really any different to learning a language
feature.  So the skill in language design and evaluation is in determining 
which constructs are so common or require such complex idioms that they
should be supported directly by the language.  IMNHO, MI is such a feature.

Paul.


-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Design By Contract

[Jon S Anthony]

In article <5ulurp$aj8$1@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:

> These are wise words.  On the other hand I would hold that a
> language with direct support for something is better for that thing
> than a language which requires some idiom.

I hope you realize how relative this is to the problem space.  Those
who _really_ believe this have pursued the path of Application
Specific Languages (ASLs), often with automatic generation (so called
"meta generators").

Another option is CL, where you can basically build your own ASLs via
macros (I suppose this counts as a kind of "meta idiom" as it is very
typical technique in CL programming).


> 2: Its harder to optimise.  I suspect that MI in Ada provides another
>    good example here.  In Eiffel the various jump tables needed for MI
>    can be optimised, for example by eliminating duplication.  As far as
>    I can see you can't do that in Ada because the compiler does not have
>    the necessary information about what the programmer is doing.
> 
> (BTW, I would be very interested in more information about that last point).

I see absolutely nothing to justify this position.  The instantiations
happen at compile time and full information is available about what is
happening.


> Of course, this on its own would be an argument for a very large and
> complex language with specific support for just about everything.  This

Not necessarily.  Again, take a look at CL.


> feature.  So the skill in language design and evaluation is in determining 
> which constructs are so common or require such complex idioms that they
> should be supported directly by the language.

This sounds right to me.


>  IMNHO, MI is such a feature.

And in mine, it's clearly _not_.  If you are going to run down this
sort of road, multiple dispatch (ala' CLOS) seems _clearly_ more
fundamental than MI.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Building blocks (Was: Design By Contract)

[Joachim Durchholz]

Geert Bosch wrote:
> I find that it is often better to combine simple building blocks
> into the more complex one you need, than to use a more complex
> feature that is not exactly what you need and may be overkill. When
> combining ill-defined over-complex things like MI, C++ templates
> and exceptions, you know for sure the result will be too complex
> and not what you want.

That myth again...
MI by itself is neither complex nor ill-defined. Its C++ implementation
is. If you want to see MI How It Should Be Done, look at one of the
various Eiffel books.

On the "building blocks" argument, I agree. Of course this will work
only if language features are truly orthogonal. C++ is extremely bad in
this respect, Ada is ways better (Eiffel really shines here, one has to
actually look at the language to believe it).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Building blocks (Was: Design By Contract)

[Paul Johnson]

In article <5un58u$9ih$1@gonzo.sun3.iaf.nl>, geert@gonzo.sun3.iaf.nl says...

>Paul Johnson <paul.johnson@gecm.com> wrote:

[On language features versus idiomatic programming]

>   For example Eiffel has direct support for multiple inheritance
>   (MI).  Ada requires you to play games with generic parameters
>   in order to achieve the same effect.''
>
>I find that it is often better to combine simple building blocks
>into the more complex one you need, than to use a more complex
>feature that is not exactly what you need and may be overkill.

[Experiences based on Ada versus C++ omitted]

Please don't judge a language feature (*any* feature) by its implementation
in C++.  The language is a bodge.

Take a look at Eiffel instead.  

> When
> combining ill-defined over-complex things like MI, C++ templates
> and exceptions, you know for sure the result will be too complex
> and not what you want.

And if you do it in C++ I'd agree with you.  However in Eiffel you will
find that MI, templates and exceptions all fit together in a unified
whole.  In fact the Eiffel exception mechanism is superior to the Ada one
because it is built on a theoretical model of software engineering.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Building blocks (Was: Design By Contract)

[Brian Rogoff]

On 8 Sep 1997, Paul Johnson wrote:
> Please don't judge a language feature (*any* feature) by its implementation
> in C++.  The language is a bodge.

If you read comp.lang.ada, you might learn that some people find certain
aspects of C++ interesting, perhaps even worthy of being considered for 
inclusion in a future Ada :-). I suggest that you abandon your programming
language religion when posting to multiple children of comp.lang. 

> Take a look at Eiffel instead.  

I have. And I used Sather for quite a while too. I find Ada superior to
both, though I confess that I find Sather iterators extremely elegant and 
more importantly I wish garbage collection was the "default" for Ada.
I think the module-type conflation is really confusion, and that OO is not 
the uber-paradigm which subsumes all others. 

> And if you do it in C++ I'd agree with you.  However in Eiffel you will
> find that MI, templates and exceptions all fit together in a unified
> whole.  In fact the Eiffel exception mechanism is superior to the Ada one
> because it is built on a theoretical model of software engineering.

I find it rather funny that in one post you say you don't use Ada, and
can't understand the idioms for doing MI in Ada, but somehow you just
"know" that it is a fact that the Eiffel exception mechanism is superior 
to Ada's. Ada exceptions can do everything Eiffel's can and more. (And
before that "goto" vs "structured" analogy gets going, I find the extra 
power useful).

Eiffel's inheritance is based on a theoretical model which later turned out 
to be unsafe. A (theoretical) fix was proposed, and never implemented. And
now we have another theoretical fix. So much for Eiffel theoretical
models! :-)

-- Brian

Re: Building blocks (Was: Design By Contract)

[Veli-Pekka Nousiainen]

Unsafe? what is unsafe in Eiffel inheritance? And what is the fix? 
I have joined in much too late... 
VP 

Brian Rogoff <bpr@shellx.best.com> wrote in article
<Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>...
<SNIP> 
> Eiffel's inheritance is based on a theoretical model which later turned
out 
> to be unsafe. A (theoretical) fix was proposed, and never implemented.
And
> now we have another theoretical fix. So much for Eiffel theoretical
> models! :-)
> 
> -- Brian
> 

Re: Building blocks (Was: Design By Contract)

[Jon S Anthony]

In article <01bcbd1d$72196760$108142c1@Yeif-1.eiffel.fi> "Veli-Pekka Nousiainen" <vp.nousiainen@remove_this_eiffel.fi> writes:

> Unsafe? what is unsafe in Eiffel inheritance? And what is the fix? 
> I have joined in much too late... 
> VP 

The polymorphic "CAT call" stuff, which rests ultimately on covariance
which is one of the basic tenets underlying Eiffel's inheritance
model.

/Jon

> Brian Rogoff <bpr@shellx.best.com> wrote in article
> <Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>...
> <SNIP> 
> > Eiffel's inheritance is based on a theoretical model which later turned
> out 
> > to be unsafe. A (theoretical) fix was proposed, and never implemented.
> And
> > now we have another theoretical fix. So much for Eiffel theoretical
> > models! :-)
> > 
> > -- Brian
> > 
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Building blocks (Was: Design By Contract)

[Veli-Pekka Nousiainen]

Unsafe? what is unsafe in Eiffel inheritance? And what is the fix? 
I have joined in much too late... 
VP 

Brian Rogoff <bpr@shellx.best.com> wrote in article
<Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>...
<SNIP> 
> Eiffel's inheritance is based on a theoretical model which later turned
out 
> to be unsafe. A (theoretical) fix was proposed, and never implemented.
And
> now we have another theoretical fix. So much for Eiffel theoretical
> models! :-)
> 
> -- Brian
> 

Re: Building blocks (Was: Design By Contract)

[Matthew Heaney]

In article <Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>,
Brian Rogoff <bpr@shellx.best.com> wrote:

>>In fact the Eiffel exception mechanism is superior to the Ada one
>> because it is built on a theoretical model of software engineering.

Can any of the Eiffel guys explain this a bit more?  I'm curious what is
meant by a "theoretical model of software engineering."  Can someone post
some references to the theory behind the Eiffel exception mechanism?

I've always been curious about the semantics of exception propagation,
because it doesn't correspond to anything in pure math (or does it?).  If I
divide x by 0 on paper, I can strug my shoulders and say, "Oh well,
division by 0 isn't defined," but on a computer, I have to do _something_. 


I just finished the Gordon book on denotational semantics, and even he just
sort of says "return {error}"; maybe the Stoy book has something more.

I read the Luckham paper, and he presented the idea that an assertion be
associated with each exception raised by a subprogram, to describe the
state when the exception is propagated.

It would be cool if you could check at compile time that all exceptions
were being handled by the client, and that only the exceptions advertised
by a supplier get raised (and only in the specified state).  Maybe that's
the Eiffel model already.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Building blocks (Was: Design By Contract)

[Brian Rogoff]

On Tue, 9 Sep 1997, Matthew Heaney wrote:

> In article <Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>,
> Brian Rogoff <bpr@shellx.best.com> wrote:
> 
> >>In fact the Eiffel exception mechanism is superior to the Ada one
> >> because it is built on a theoretical model of software engineering.

Watch your attributions, I didn't write that!

> Can any of the Eiffel guys explain this a bit more?  I'm curious what is
> meant by a "theoretical model of software engineering."  Can someone post
> some references to the theory behind the Eiffel exception mechanism?

The original poster probably meant that the Eiffel exception mechanism was 
designed to support Eiffel design by contract, so that when an exception is 
raised you retry or fail, restoring class invariants on leaving. I doubt he 
was talking about denotational semantics or theoretical models like that!

You can read about DBC in Meyer's book or one of the many articles he's 
written. 

-- Brian

Re: Building blocks (Was: Design By Contract)

[W. Wesley Groleau x4923]

> It would be cool if you could check at compile time that all exceptions
> were being handled by the client, and that only the exceptions advertised
> by a supplier get raised (and only in the specified state).  Maybe that's
> the Eiffel model already.

Well, that's one good thing you can say about Java.  Or is it (good)?

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Building blocks (Was: Design By Contract)

[Robert A Duff]

In article <3415BA96.19B1@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>> It would be cool if you could check at compile time that all exceptions
>> were being handled by the client, and that only the exceptions advertised
>> by a supplier get raised (and only in the specified state).  Maybe that's
>> the Eiffel model already.
>
>Well, that's one good thing you can say about Java.  Or is it (good)?

No, it's not good.  It leads to "crying wolf" -- that is, one must state
that so-and-so might raise such-and-such exception, even when it's
obvious it won't.  Consider, for example, the stream classes in Java.  A
stream that represents a sequence of bytes read from an in-memory array
has to falsely state that it might raise various I/O related exceptions,
despite the fact that it has nothing whatsoever to do with I/O.

The sentiment here is good, but it doesn't work given the paricular
rules of Java, IMHO.  Perhaps a different set of language rules could
achieve the benefits without the "crying wolf" problems.

- Bob

Re: Building blocks (Was: Design By Contract)

[Jon S Anthony]

In article <EG9ruK.BIq@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> >> It would be cool if you could check at compile time that all exceptions
> >> were being handled by the client, and that only the exceptions advertised
> >> by a supplier get raised (and only in the specified state).  Maybe that's
> >> the Eiffel model already.
> >
> >Well, that's one good thing you can say about Java.  Or is it (good)?
> 
> No, it's not good.  It leads to "crying wolf" -- that is, one must state
> that so-and-so might raise such-and-such exception, even when it's
> obvious it won't.  Consider, for example, the stream classes in Java.  A
> stream that represents a sequence of bytes read from an in-memory array
> has to falsely state that it might raise various I/O related exceptions,
> despite the fact that it has nothing whatsoever to do with I/O.
> 
> The sentiment here is good, but it doesn't work given the paricular
> rules of Java, IMHO.  Perhaps a different set of language rules could
> achieve the benefits without the "crying wolf" problems.

CORBA IDL has this same problem.  Actually, it may have influenced the
Java model as it certainly came B4 Java (I wonder if this bit of IDL
can be traced back to Sun....)

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Building blocks (Was: Design By Contract)

[Paul Johnson]

In article <mheaney-ya023680000909970121270001@news.ni.net>, mheaney@ni.net 
says...

>In article <Pine.SGI.3.95.970908193446.11288B-100000@shellx.best.com>,
>Brian Rogoff <bpr@shellx.best.com> wrote:

>>>In fact the Eiffel exception mechanism is superior to the Ada one
>>> because it is built on a theoretical model of software engineering.

Brian Rogoff didn't write that, I did.

>Can any of the Eiffel guys explain this a bit more?  I'm curious what is
>meant by a "theoretical model of software engineering."  Can someone post
>some references to the theory behind the Eiffel exception mechanism?

I was referring to "design by contract", which underpins pretty much the
whole of Eiffel.  See OOSC-2 for the fullest explanation yet.  E:TL also
has quite a lot of stuff about it, and the theory was laid out in OOSC-1
in enough detail for a first pass.  I think that there is also an outline
on the ISE web site (www.eiffel.com).

>I've always been curious about the semantics of exception propagation,
>because it doesn't correspond to anything in pure math (or does it?).

Under DbC, the server class offers a "contract" specified by the
preconditions, postconditions and invariants.  When a routine is called,
the client must fulfil the preconditions (otherwise there is a bug in
the client).  Once these preconditions are fulfilled the server class
must either fulfil the postconditions and invariants *or* raise an
exception.  In everyday programming this just means that it must fulfil
its postconditions and invariants, but for instance an RPC mechanism
might trigger an exception if it discovers that the network is down.

Once an exception has been triggered the class has two options:

1. Tidy up any internal state and pass the exception back to the caller.

2. Try again, possibly using a different stratagy.

Note that there is no third option.  Also note that the following are
forbidden:

* Silent failure.  If the server cannot fulfil its contract then it *must*
  raise an exception.

* Exceptions as normal control structure.  An exception indicates that
  something has gone wrong: things are not working as intended.  It might
  be that the "something" is outside the software's control (e.g. network
  down) and the software has been written to handle this gracefully, but
  there is still something wrong.  A dictionary lookup routine does not
  return an exception if it fails to find an entry.

>It would be cool if you could check at compile time that all exceptions
>were being handled by the client, and that only the exceptions advertised
>by a supplier get raised (and only in the specified state).  Maybe that's
>the Eiffel model already.

In Eiffel there is not much distinction between exceptions.  You can
examine an exception, but thats more so you can put something useful 
in the error log than for any control-flow reasons.  As far as control
flow is concerned, the key fact is that the routine has failed.  Nothing
else matters.

In Ada exceptions seem to be treated as a sort of out-of-band enumerated
type.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Building blocks (Was: Design By Contract)

[Matthew Heaney]

In article <5v5l26$h62$3@miranda.gmrc.gecm.com>, paul.johnson@gecm.com
(Paul Johnson) wrote:


>In Ada exceptions seem to be treated as a sort of out-of-band enumerated
>type.

It depends on the programmer - I have have seen many of the abuses you
describe.  However, I personally use Ada exceptions exactly as you
recommend.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Building blocks (Was: Design By Contract)

[Darren New]

>Note that there is no third option.  Also note that the following are
>forbidden:
>
>* Silent failure.  If the server cannot fulfil its contract then it *must*
>  raise an exception.
>
>* Exceptions as normal control structure.  An exception indicates that
>  something has gone wrong: things are not working as intended. 

Elaborating: Actually, I think the theoretical basis for the exceptions
are that you cannot catch an exception and continue on. For example,
if your calling code says

  x := him.blah(y)
  fooble(x)

then if him.blah has a postcondition that Result>0, fooble can rely
on getting an argument whose value is > 0.  If him.blah fails to
return the value that meets the postcondition, an exception is raised
and passed to the caller. Hence, it is *impossible* to call fooble
here with a negative value for x.  There is no equivalent of
  try { x := him.blah(y) } catch (...) { /* do nothing */ }
  fooble(x)

If every line of code does not fulfill its postconditions, it's impossible
to execute the following line. And *that* I believe is what makes
the exception mechanism helpful in reasoning about your code.

Of course, it's also helpful that you do not have to catch errors in
the wrong place.  I very much dislike the Java mechanism when I try
to implement an interface that does not throw IOException (for example)
and I'm doing IO, so I have to figure out what the client is likely
to want in terms of error handling, making reuse difficult. There are
ways around it, but it's kludgey.
  -- Darren

Re: Building blocks (Was: Design By Contract)

[Robert Dewar]

Brian Rogoff said

<<>>In fact the Eiffel exception mechanism is superior to the Ada one
>> because it is built on a theoretical model of software engineering.>>

This is one of the more absurd statements in what is unfortunately becoming
a rather tedious thread. First of all, the idea that being "built on
*a* (i.e. any old) theoretical model of software engineering" is per se
a good thing is a bit laughable.

Second, of course the Ada exception mechanism is build on such a model
also -- indeed it *is* a model itself!

Rather thank make vague religeous statements like this which have 
zero meaning, say EXACTLY what technical point you are trying to make.

Re: Building blocks (Was: Design By Contract)

[Jon S Anthony]

In article <dewar.873938975@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Brian Rogoff said
> 
> <<>>In fact the Eiffel exception mechanism is superior to the Ada one
> >> because it is built on a theoretical model of software engineering.>>
> 
> This is one of the more absurd statements in what is unfortunately becoming
> a rather tedious thread. First of all, the idea that being "built on
> *a* (i.e. any old) theoretical model of software engineering" is per se
> a good thing is a bit laughable.

Coming to Brian's defense here: He didn't say this, Paul Johnson said
it.  However, I fully agree with your characterization of the statement.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Building blocks (Was: Design By Contract)

[Robert Dewar]

Jon said

<<> Brian Rogoff said
>
> <<>>In fact the Eiffel exception mechanism is superior to the Ada one
> >> because it is built on a theoretical model of software engineering.>>
>
> This is one of the more absurd statements in what is unfortunately becoming
> a rather tedious thread. First of all, the idea that being "built on
> *a* (i.e. any old) theoretical model of software engineering" is per se
> a good thing is a bit laughable.

Coming to Brian's defense here: He didn't say this, Paul Johnson said
it.  However, I fully agree with your characterization of the statement.>>


Gosh, another horrible attribution error, that's twice in a week. Sorry
about that Brian!

Re: Building blocks (Was: Design By Contract)

[Brian Rogoff]

On 12 Sep 1997, Robert Dewar wrote:
> <... I'm not including anything, it ends here :-) ...> 
> 
> Gosh, another horrible attribution error, that's twice in a week. Sorry
> about that Brian!

Ego te absolvo, Robert! :-) 

I agree that it would be nice if there were a more automatic way to
determine who said what, when. 

-- Brian 

Re: Building blocks (Was: Design By Contract)

[Paul Johnson]

In article <dewar.873938975@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>Brian Rogoff said
>
><<>>In fact the Eiffel exception mechanism is superior to the Ada one
>>> because it is built on a theoretical model of software engineering.>>

As someone else pointed out, I said that, not Brian.

>This is one of the more absurd statements in what is unfortunately becoming
>a rather tedious thread. First of all, the idea that being "built on
>*a* (i.e. any old) theoretical model of software engineering" is per se
>a good thing is a bit laughable.

In the original posting I was trying to be brief.  I have since
explained about design by contract and the Eiffel exception mechanism.

>Second, of course the Ada exception mechanism is build on such a model
>also -- indeed it *is* a model itself!

If I understand you correctly, the Ada exception mechanism looks like it
does because that was how the designers designed it.  My original point
was that the Eiffel mechanism looks like it does because the theory of
software contracting required it to work that way.

Actually I don't believe that the Ada designers just threw together its
exception mechanism without thinking long and hard, and I don't think
you really meant to imply it.  However the lack of an underlying theory
on its use and contribution to program correctness definitely shows up.
Ada exceptions seem to have been designed as a way of unwinding the
execution stack without letting the programmer break the language.  The
only reason for including it in the language was that programmers often
want to do this.

Paul.

--------------------------------+---------------------------------
Paul Johnson                    | You are lost in a maze of twisty
Email: Paul@treetop.demon.co.uk | little standards, all different.
       paul.johnson@gecm.com    |

Re: Building blocks (Was: Design By Contract)

[Robert Dewar]

Paul said

<<Actually I don't believe that the Ada designers just threw together its
exception mechanism without thinking long and hard, and I don't think
you really meant to imply it.  However the lack of an underlying theory
on its use and contribution to program correctness definitely shows up.
Ada exceptions seem to have been designed as a way of unwinding the
execution stack without letting the programmer break the language.  The
only reason for including it in the language was that programmers often
want to do this.
>>


No need to believe or not believe anything here (actually you really use
believe as a synonym for guess, but there is no need to guess). if you
want to make statements about Ada Exception handling which you expect any
one to pay attention to, do a little homework. And in particular, study
the extensive material that is available to answer your question without
guesses (your "seems to have been designed" is complete nonsense, as you
will see if you do this homework!)

Re: Building blocks (Was: Design By Contract)

[Robert Dewar]

<<In the original posting I was trying to be brief.  I have since
explained about design by contract and the Eiffel exception mechanism.>>

It is not at all the case that the abstract notion of design by contract
dictates the design of the detailed syntax of the exception mechanism.
Of course (as anyone familiar with the Ada design process are very aware),
the Ada design of specifications is entirely focussed on the issue of what
elements of the interface contract belong in the syntax of the language and
what are best left to comments. The same statement can of course be made
in Eiffel, so the theoretical bases, or more accurately, the fundamental
design principles, are in fact very similar.

The specific issue in Ada of whether it should be part of the syntax of
the language to specify the exceptions that can be raised is of course
one that was extensively discussed, and the quite deliberate decision was
made that it is unhelpful to require these to be stated in the syntax.

The reason is that there are too many exceptions (Storage_Error, or the
various IO errors if any IO is done, or other application defined system
wide exceptions) which would be named all over the place and create clutter.
Note that Program_Error would also have to be named almost everwhere because
of the Access Before Elaboration (ABE) considerations.

SO there is no question of a presence or lack of theory here, rather it is
a pragmatic issue of what should and should not go into the syntactical
interface. Eiffel generally decides to put more into the syntax, but there
is no real evidence to suggest that this is a good thing, it's mostly a
subjective issue.

Re: Building blocks (Was: Design By Contract)

[John G. Volan]

Robert Dewar wrote:
> 
> The specific issue in Ada of whether it should be part of the syntax of
> the language to specify the exceptions that can be raised is of course
> one that was extensively discussed, and the quite deliberate decision was
> made that it is unhelpful to require these to be stated in the syntax.
> 
> The reason is that there are too many exceptions (Storage_Error, or the
> various IO errors if any IO is done, or other application defined system
> wide exceptions) which would be named all over the place and create clutter.
> Note that Program_Error would also have to be named almost everwhere because
> of the Access Before Elaboration (ABE) considerations.

There are a couple of strategies that could be applied to this problem:

(1) Take certain common language-defined exceptions as givens (e.g.,
Storage_Error, Program_Error, Constraint_Error).  That is to say, assume
that they are implicitly part of the interface of every
subprogram/method, and don't require the programmer to explicitly list
them.

(2) Make exceptions first-class objects, and take advantage of class
hierarchies to simplify subprogram/method interfaces.  For instance, IO
exceptions might be organized into a hierarchy rooted at some abstract
IO_Exception class.  A method could declare that it can raise any
IO_Exception, without having to explicitly list all the subclasses.

As I understand it, this is essentially the strategy Java uses.  I must
admit that I like being able to treat exceptions as first-class objects
organized in class hierarchies, and I miss that capability in Ada95.  I
wonder why this notion didn't catch on in the Ada95 design ... is it
because first-class exceptions would have introduced a so-called
"distributed overhead" into the language?

-- 
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

Re: Building blocks (Was: Design By Contract)

[Robert Dewar]

<<If I understand you correctly, the Ada exception mechanism looks like it
does because that was how the designers designed it.  My original point
was that the Eiffel mechanism looks like it does because the theory of
software contracting required it to work that way.>>

No, that is completely wrong, and if you want to find out why you are
wrong, you should read the Ada Rationale. 

Re: Building blocks (Was: Design By Contract)

[W. Wesley Groleau x4923]

> > whole.  In fact the Eiffel exception mechanism is superior to the 
> > Ada one because it is built on a theoretical model of software 
> > engineering.

Theory is a good thing when it leads to progress.  After it is 
confirmed by practical experience, it remains a good thing.
As soon as it disagrees with practical experience, it becomes
a Bad Thing.

Ada's design had plenty of "theory" behind it.  But it also had
plenty of experienced people to shoot down any tendency to put
excessive faith in theory.

I can't personally say Eiffel's experience supports or disproves
its theory.  (Obviously, there are plenty of people already saying
it supports it.)  But I can say that "built on a theoretical model"
is certainly no argument for superiority over Ada, or even over C.

To change a word in an earlier quote:
"A man with an experience is never at the mercy of
 a man with a theory."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Design By Contract

[Nick Leaton]

> These are wise words.  On the other hand I would hold that a language with
> direct support for something is better for that thing than a language which
> requires some idiom.

There are some exceptions to this. I agree with you on MI for example, but if the 
idiom is particularly easy to express or occurs rarely, then there is no need 
to extend the language to cope. Having, somewhere in the language specification, 
a note on the idiom helps, because at least the solution is standard.

> For example Eiffel has direct support for multiple inheritance (MI).  Ada
> requires you to play games with generic parameters in order to achieve
> the same effect.
>  
> Here are the reasons I dislike idiomatic programming:
>  
> 1: Its harder to read.  The reader must "reverse engineer" the design
>    of the system by looking at the idiom and recognising it.  This
>    generally requires that the reader be familiar with the idiom in
>    question.  I recall being totally flumoxed when I was learning
>    assembler and came across my first "JMP" instruction at the end of
>    a routine.  Later of course, I learned the trick and would now understand
>    such code.

Its like learning a spell which you must chant to protect yourself.

..

Nick

Re: Design By Contract

[Matthew Heaney]

In article <VA.0000004d.486c7bde@nickle.compulink.co.uk>,
nickle@compulink.co.uk wrote:


>> For example Eiffel has direct support for multiple inheritance (MI).  Ada
>> requires you to play games with generic parameters in order to achieve
>> the same effect.

Thinking more about it, it really does make sense to implement mixin
inheritance this way in Ada 95.  The original poster probably wasn't
"thinking in Ada."  

To declare an abstract data type in Ada, you do this:

package P is

   type T is tagged private;
...
end;

Clients of type T with package P to get visibility to the type:

with P;
procedure Q is
   O : P.T;
...

Now as far as clients of T are concerned, it doesn't matter whether P is a
non-generic package, or the instantiation of a generic package.  His
manipulation of the type is the same.  For example, we could have done
this:

generic
   ...
package GP is 
   type T is tagged ...;
...

package P is new GP (...);

My point is that from a client's point of view, it's exactly the same.  He
wants a type that has certain operations, so he withs a package containing
that type.

Now we have a certain abstraction into which we want to mix some other
operations.  What we're debating is how easy it is for the _mixer_ to do
this.  But who made this executive decision that MI is a better mechanism
than genericity for combining abstractions?

The key thing is that we're able to combine abstractions this way,
_without_ an additional language feature.  (This doesn't mean MI is bad,
only that it's not needed.)  Existing language mechanisms do _exactly_ what
we want.  The irony is that this isn't anying especially new: in Ada 83 we
were _already_ combining abstractions this way (example: extending a list
type with utility operations by importing the list type as a generic formal
parameter).

To say that MI is a "more elegant' mechanism of implementing mixin
inheritance, or that Ada requires you to "play games" with generics (thus
reducing the Ada mechanism to the status of a mere "idiom"), is a pretty
impuissant argument.  (Like my new word?)  The generic technique is what
Ada programmers have been doing all along (though not quite as simply as in
Ada 95), so I'm not clear what you'd buy by using yet another mechanism
whose superiority is only putative.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Design By Contract

[Paul Johnson]

In article <VA.0000004d.486c7bde@nickle.compulink.co.uk>, 
nickle@compulink.co.uk says...
>
>> These are wise words.  On the other hand I would hold that a language with
>> direct support for something is better for that thing than a language which
>> requires some idiom.
>
>There are some exceptions to this. I agree with you on MI for example, but if 
the 
>idiom is particularly easy to express or occurs rarely, then there is no need 
>to extend the language to cope. Having, somewhere in the language 
specification, 
>a note on the idiom helps, because at least the solution is standard.

Absolutely.  I was careful in my original posting to say that direct
support makes a language better *for that thing*.  Of course an extra
feature makes the language worse for other things.  This is the balance
that must be struck.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Design By Contract

[Jon S Anthony]

In article <EFzLn7.481@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >mechanism is clearly "simpler".  b) can be done at a certain level via
> >appropriate combination of public/private children, but it is not as
> >encompassing as selective export.  Then again, I've never had the
> >experience where this extra selectivity would have been useful.
> 
>   I had an experience where selective export was really useful.  I was
> writing a circuit simulator, and I was using the builder pattern to
> decouple the representation of the circuit from its construction.  I
> created features to add components and join them with wires.
> 
>   Then there was a CIRCUIT_SIMULATOR class which managed the event
> queue for a circuit.  It needed the ability to cause the circuit to
> enact events, but I didn't want the builder to be able to enact
> events because a) the circuit is not complete and b) the output
> channel for the results of the simulation is not yet ready.
> 
>   Thus, I exported the circuit's enact_event feature to CIRCUIT_SIMULATOR
> and solved that problem in a very straightforward way.  

Yes, but this is a good example of something that private children are
intended for and which is straightforward to achieve with them.  It is
not a counter example to the "extra selectivity" capability of
selective export.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[W. Wesley Groleau x4923]

> :> I still prefer the Eiffel mechanisms for a couple reasons:
> :>
> :>   a) Simpler
> :>   b) Views may be directed to specific clients
> :
> :Well, OK, but ....
> :b) can be done at a certain level via
> :appropriate combination of public/private children, but it is not as
> :encompassing as selective export.

I would say that public children allows selective import, and 
the "appropriate combination of public/private children" allows
export to be selective, but only to the extent of choosing to
export within the group or to everyone.

> The sort of situations where it is handy is for tightly-knit 
> 

And in Ada a tightly-knit abstractions might be a collection 
of private children.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: subjectivity

[W. Wesley Groleau x4923]

> :>   a) Simpler
> :>   b) Views may be directed to specific clients
> :
> :Well, OK, but a) is subjective and viewed another way, the Ada
> :mechanism is clearly "simpler".
> 
> Looks like we have different ideas of what is simple. :(

Which is why it is subjective.  Unless we define "simple" as
"easy for the speaker to use because he/she is accustomed to it."

> I know you'll probably disagree, ..., but I believe simplicity is 
> innately, universally, and uniformly recognisable by everyone. 
> It's an aspect of human perception that occurs
> automatically and intantaneously without conscious thought.
> Because its a *perceived* quality, some believe it to be subjective.

Since you and other(s), by your own admission, have "different 
ideas of what is simple," you should acknowledge that it is not
"uniformly recognisable by everyone."  Hence, it is subjective
except when, in a particular forum, all participants agree on
(in your words) "what measurable qualities engender the notion
of simplicity and ... an 'objective' basis for measuring it."

But perhaps this topic is ready to join Emmanuel Kant and
Ayn Rand over on gnu.misc.discuss

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: subjectivity

[Matthew Heaney]

In article <341026A7.37BE@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923"
<wwgrol@pseserv3.fw.hac.com> wrote:

>Since you and other(s), by your own admission, have "different 
>ideas of what is simple," you should acknowledge that it is not
>"uniformly recognisable by everyone."  Hence, it is subjective
>except when, in a particular forum, all participants agree on
>(in your words) "what measurable qualities engender the notion
>of simplicity and ... an 'objective' basis for measuring it."

Here's a quote relevent to this thread:

The idea that complexity is directly related to people's psychological
being was recognized by Ashby.  He argues that complexity depends on
people's interests:

"to the neurophysiologist the brain, as a feltwork of fibers and a soup of
enzymes, is certainly complex; and equally the transmission of a detailed
description of it would require much time.  To a butcher the brain is
simple, for he has to distinguish it from only about thirty other "meats.""

From Dealing with Complexity, by Flood and Carson

They also observe that

"In general, we associate complexity with anything we find difficult to
understand."

That's why complexity can only be understood by considering both people
_and_ things.  There is no such thing as an "objective" measure of
simplicity or complexity, because humans are involved, and every human has
a different view of the system, depending on his interest.  To the butcher,
the brain isn't complex at all.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: subjectivity

[Don Harrison]

Matthew Heaney wrote:

:Here's a quote relevent to this thread:
:
:The idea that complexity is directly related to people's psychological
:being was recognized by Ashby.  He argues that complexity depends on
:people's interests:
:
:"to the neurophysiologist the brain, as a feltwork of fibers and a soup of
:enzymes, is certainly complex; and equally the transmission of a detailed
:description of it would require much time.  To a butcher the brain is
:simple, for he has to distinguish it from only about thirty other "meats.""
:
:From Dealing with Complexity, by Flood and Carson

Nice quote.

:They also observe that
:
:"In general, we associate complexity with anything we find difficult to
:understand."

Good definition.

:That's why complexity can only be understood by considering both people
:_and_ things.  There is no such thing as an "objective" measure of
:simplicity or complexity, because humans are involved, and every human has
:a different view of the system, depending on his interest.  To the butcher,
:the brain isn't complex at all.

The interest factor may be quite relevant here. My interest in minimality,
uniqueness etc. certainly colours my own perception of simplicity.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: subjectivity

[Jon S Anthony]

In article <EGA65A.G1s@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> The interest factor may be quite relevant here. My interest in minimality,
> uniqueness etc. certainly colours my own perception of simplicity.

That's not all there is to it.  What is being "minimized" and what is
"unique" plays a central role as well.  Minimizing "good" is not
exactly what most people would pursue simply because it is
"minimizing"...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: subjectivity

[Don Harrison]

Jon S Anthony wrote:

:In article <EGA65A.G1s@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
:
:> The interest factor may be quite relevant here. My interest in minimality,
:> uniqueness etc. certainly colours my own perception of simplicity.
:
:That's not all there is to it.  What is being "minimized" and what is
:"unique" plays a central role as well.  

Agree. Also, qualities may be beneficial in one *sense* and not another.
For example, one could argue that minimal language mechanisms make a 
language easier to understand. 

But from another perspective, code implemented in such a language may be 
less easy to understand because more statements are required. This is one 
reason why reuse becomes so important when using minimalist languages.

Further, minimalism has a performance overhead so increases the burden on 
compiler writers to optimise extensively. 

While there may be factors which derail it, this may be an argument in 
favour of Ada's "richness". Oops, I'd better take that back - I'm supposed 
to be a closed-minded language bigot!  :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: subjectivity

[Jon S Anthony]

In article <EGL5CK.5IA@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> :That's not all there is to it.  What is being "minimized" and what is
> :"unique" plays a central role as well.  
> 
> Agree. Also, qualities may be beneficial in one *sense* and not another.
> For example, one could argue that minimal language mechanisms make a 
> language easier to understand. 
> 
> But from another perspective, code implemented in such a language may be 
> less easy to understand because more statements are required. This is one 
> reason why reuse becomes so important when using minimalist languages.

Yes, I completely agree.  This differing perspectives looking into/at
the same subject is the perceptive mode of investigation.  The more
such "legitimate" (which may be an issue itself) perspectives the
clearer the issue will become.


> Further, minimalism has a performance overhead so increases the
> burden on compiler writers to optimise extensively.

Right - or sometimes the other way 'round.


> While there may be factors which derail it, this may be an argument
> in favour of Ada's "richness". Oops, I'd better take that back - I'm
> supposed to be a closed-minded language bigot!  :)

;-), but yes, I think that from certain perspectives this is a plus
and from others it may be a minus.  Yes, exactly.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: subjectivity

[Don Harrison]

W. Wesley Groleau wrote:
:
:> :>   a) Simpler
:> :>   b) Views may be directed to specific clients
:> :
:> :Well, OK, but a) is subjective and viewed another way, the Ada
:> :mechanism is clearly "simpler".
:> 
:> Looks like we have different ideas of what is simple. :(
:
:Which is why it is subjective.  

No, it just means the concept of simplicity is probably being confused with 
something else - familiarity or ease-of-use, for example.

: Unless we define "simple" as
:"easy for the speaker to use because he/she is accustomed to it."

You could but I think it would miss the mark. Ease-of-use can be due to a number
of factors including familiarity and simplicity. 

If you're familiar with a language tool, it will tend to be easier to use
but that doesn't necessarily mean it's simple. Also, if a tool is simple,
it will tend to make it easy to use but may not be immediately so due to a 
lack of familiarity - the learning curve effect. If a tool is neither familiar
nor simple (as APL was to me when I learnt it), it definitely won't be easy 
to use (and it wasn't).

Simplicity tends to engender ease of use but is constrained by familiarity.
Familiarity tends to engender ease of use but is constrained by simplicity.

My experience of discovering Eiffel demonstrates these effects. It was 
immediately clear to me that Eiffel was simpler than Ada in spite of my 
familiarity with Ada. Just because it was simple didn't immediately make it
easier to use, the reason being that it was unfamiliar. In particular, I wasn't
familiar with the various idioms of OO in general, and Eiffel in particular, 
that would enable me to use it effectively. I'm still learning them.

Clearly, if simplicity were the same as ease-of-use due to familiarity, I 
would have found Eiffel complex compared with Ada, but I didn't.

:> I know you'll probably disagree, ..., but I believe simplicity is 
:> innately, universally, and uniformly recognisable by everyone. 
:> It's an aspect of human perception that occurs
:> automatically and intantaneously without conscious thought.
:> Because its a *perceived* quality, some believe it to be subjective.
:
:Since you and other(s), by your own admission, have "different 
:ideas of what is simple," you should acknowledge that it is not
:"uniformly recognisable by everyone."  

I still think it is, if they take the trouble to identify personal bias.
The signal is trying to get through to the brain, but other things such as
familiarity and pre-conceived ideas are intent on derailing it. If we 
identified and filtered out those interfering factors, we would have the 
same perception of simplicity, IMO. 

Considering that is unlikely to happen, it's useful to circumvent that 
interference by examining the factors that give rise to the notion of 
simplicity. These factors, at least, are objective and provide a basis for 
comparison.

:Hence, it is subjective
:except when, in a particular forum, all participants agree on
:(in your words) "what measurable qualities engender the notion
:of simplicity and ... an 'objective' basis for measuring it."

Sadly true.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: subjectivity

[W. Wesley Groleau x4923]

> If you're familiar with a language tool, it will tend to be easier to 
> use but that doesn't necessarily mean it's simple. 

Right.  And if you think a feature of your favorite language is 
simple, you are either correct by your definition of simplicity
or you are a closed-minded language bigot.  No offense should be
taken unless you _want_ to consider yourself the latter. :-)

> My experience of discovering Eiffel demonstrates these effects. 
> It was immediately clear to me that Eiffel was simpler than Ada in 
> spite of my familiarity with Ada. 

It was immediately clear to you that Eiffel met your idea of 
simplicity.  (Or it could be "I like Eiffel, Simplicity is good, 
therefore Eiffel is simple.)

There are things in the Ada RM that I (and most Ada folks) do not 
consider simple, but which are the reason why certain things in
Ada programs _are_ considered simple.  So even when we agree on 
what is simple, it's still subjective.

Since "definitions" are getting into the argument, shall we go to
a meta-argument?  Define "objective" and "subjective"

When Frieda says, "X is simple" and Dana says, "No, X is complex."
then I think they have not agreed on an objective measure of
simplicity.  Don thinks that one of them is correct, and the other
is either lying, or is handicapped in the God-given ability to
recognize simplicity.  Supposing Don is right--it's still subjective
which of them is correct.  The only ways to end the argument between
Dana and Frieda are for one of them to give in, or for both of them
to agree on a measure of simplicity and apply it.  For one of them
to insist that the ability to recognize simplicity is innate will at
best move the argument to the level of whether that is true.
Then if they agree that is true, they can still argue which of them
has that ability and which is handicapped.  I think I have a 
God-given ability to recognize that this is not raising the 
argument to a higher level--it is lowering the argument several 
levels closer to idiocy.

> The signal is trying to get through to the brain, but other things 
> such as familiarity and pre-conceived ideas are intent on derailing 
> it. If we identified and filtered out those interfering factors, we 
> would have the same perception of simplicity, IMO.

Yes, if we identify the factors in my definition of simplicity that
you disagree with, and I give them up, then we will have the same
perception of simplicity.

> Considering that is unlikely to happen, it's useful to circumvent that
> interference by examining the factors that give rise to the notion of
> simplicity. These factors, at least, are objective ....

These factors are not objective until we name them, agree on what
they mean, and agree on how to measure them.

Now, IF we could come to such agreement (instead of continuing to 
argue about whether simplicity is objective), I suspect we would
be forced to also agree that in certain areas, Eiffel is simpler,
and in other areas, Ada is simpler.  It would probably still be
subjective how it plays out overall.

So again, I suggest again: State why you believe a particular feature
is an advantage or disadvantage.  Provide, if available, measurements
of results as evidence.  Then if someone else disagrees (or doesn't
think the thing you measured is important) either say to yourself
he's an idiot and keep quiet, or continue discussing the _issue_.

Whether you intended it or not, saying that something he disagrees
about is obvious is the same as saying he is either blind or a liar.
If he were either, what point is there in arguing?

This subjectivity thing (including THIS post) is a waste of time.
Let's cut it out.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: subjectivity

[W. Wesley Groleau x4923]

Don Harrison wrote:
> :> I know you'll probably disagree, ..., but I believe simplicity is
> :> innately, universally, and uniformly recognisable by everyone.
> :> It's an aspect of human perception that occurs
> :> automatically and intantaneously without conscious thought.
> :> Because its a *perceived* quality, some believe it to be subjective.

AND

> The interest factor may be quite relevant here. My interest in minimality,
> uniqueness etc. certainly colours my own perception of simplicity.

I rest my case.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: subjectivity

[Don Harrison]

Matt Heaney wrote:

:..He argues that complexity depends on people's interests..

and 

:.. we associate complexity with anything we find difficult to understand."

I wrote:

:The interest factor may be quite relevant here. My interest in minimality,
:uniqueness etc. certainly colours my own perception of simplicity.

Taking this further, we might recognise that these qualities (minimality,
uniqueness etc. promote understanding, not just in individuals, but in 
people generally. 

This leaves us with:

  Minimality, uniqueness etc. promotes 
  understandability which promotes 
  the perception of simplicity.

Caveat: I acknowledge that other people may be interested in other things - 
for example, redundancy, multiple ways of doing things, interdependencies, 
inconsistency etc.


W. Wesley Groleau wrote:

:I rest my case.

Likewise.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design By Contract

[Jon S Anthony]

In article <EG0oz8.F6M@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> Especially since you haven't shown how you think child packages can
> give some of what selective export has to offer. It's a bit
> difficult to give an example of what they *don't* offer if it's not
> clear what they *do* offer.

See Patrick's example.  The point is, private children provide a level
of "selective export" (exporting their interfaces only to their
parent's body and certain parts of the private subtrees).  IME, this
has been quite sufficient.

Eiffel's selective export is really much more like the granularity you
get (and the attendant problems from) C++ friendship.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Nick Leaton]

Jon S Anthony wrote:
> 
> In article <EG0oz8.F6M@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
> 
> > Especially since you haven't shown how you think child packages can
> > give some of what selective export has to offer. It's a bit
> > difficult to give an example of what they *don't* offer if it's not
> > clear what they *do* offer.
> 
> See Patrick's example.  The point is, private children provide a level
> of "selective export" (exporting their interfaces only to their
> parent's body and certain parts of the private subtrees).  IME, this
> has been quite sufficient.
> 
> Eiffel's selective export is really much more like the granularity you
> get (and the attendant problems from) C++ friendship.

Jon, What are the problems? I'm well aware with the issues that arise in
C++,
particularly with the all or nothing nature of C++ friendship. It is not
as if you have to reveal your implementation. Selective revealing of
interface I presume is OK, so what mechanism would you provide in its
place?

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Design By Contract

[Jon S Anthony]

In article <341041A6.E45B6425@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> > Eiffel's selective export is really much more like the granularity you
> > get (and the attendant problems from) C++ friendship.
> 
> Jon, What are the problems? I'm well aware with the issues that
> arise in C++, particularly with the all or nothing nature of C++
> friendship. It is not as if you have to reveal your
> implementation.

That's was not the issue I had in mind, it was more the "clairvoyance"
problem of export for future clients.  But really, Eiffel has a
reasonable way around that which does not fall victim to the C++
problem.

> Selective revealing of interface I presume is OK, so
> what mechanism would you provide in its place?

For something like Eiffel (where everything is defined via inheritance
based classification), I think the solution provided is reasonable.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Nick Leaton]

Jon S Anthony wrote:

> > Selective revealing of interface I presume is OK, so
> > what mechanism would you provide in its place?
> 
> For something like Eiffel (where everything is defined via inheritance
> based classification), I think the solution provided is reasonable.
> 

I found things like Eiffel's use of inheritance for getting access to
the facilities a little odd at first, but in practice it doesn't turn
out to be a problem. Having good names for these classes help. 

One use is to get access to a set of constant objects in which case
mostly we use _CONVENTION at the end of the class name.

For functions such as sin and cos, then anthropromorphise (or the code
equivalent ;-) ) the class, such as MATHEMATICIAN or STATISTICIAN.

Some of are classes here end in _CALCULATOR fall into this category.

It then makes it easy to identify or guess what the class is being used
for.

I would also put them at the end of the inheritance list if you are
using MI.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Design By Contract

[Paul Johnson]

In article <34150AE7.ABE4EDD6@calfp.co.uk>, nickle@calfp.co.uk says...

>I found things like Eiffel's use of inheritance for getting access to
>the facilities a little odd at first, but in practice it doesn't turn
>out to be a problem. Having good names for these classes help. 

I agree.  On the other hand, if you prefer not to pollute your namespace
with all the stuff from the mixin class, you can do something like this:

   feature {NONE}

      math: expanded MATH;

Now anywhere in your code you can write something like:

   a := math.sin (b)

Its a bit like the use/with clauses in Ada.

Paul.

Paul

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Design By Contract

[Patrick Doyle]

In article <JSA.97Sep5130913@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>Eiffel's selective export is really much more like the granularity you
>get (and the attendant problems from) C++ friendship.

Perhaps it's "more like" but it's certainly very, very different.
C++ has no granularity in its selective exports: you're either a
friend or you're not.  Either you're breaking encapsulation or
you're not.

In Eiffel, it's a matter of presenting different interfaces to
different classes, and the mechanism is precise enough that
encapsulation is maintained in all cases--just *different*
encapsulations.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[Matthew Heaney]

In article <EG0rp7.GtL@syd.csa.com.au>, nospam@thanks.com.au wrote:

>One obvious weakness of Ada child packages compared with Eiffel selective
>export is a lack of symmetry. With selective export, two modules can 
>selectively export to each other. It's difficult to imagine how you could do
>this elegantly with child packages, if at all. 
>
>It may be necessary in Ada to co-encapsulate under such circumstances. In 
>that case, you lose the ability to control how each object updates the other's 
>state.

This issue is frequently debated on comp.lang.ada, but I'll mention it
again.  The _reason_ modules and types are orthogonal is precisely so you
can co-encapsulate types in the same package; this is why no "friend"
instruction is needed in Ada.  If two types need access to each other's
state, then they are highly cohesive abstractions, and _should_ go in the
same package.

The argument that by using this idiom one "loses the ability to control how
each object updates each other's state" isn't an issue in real programs. 
If such control were an issue, then perhaps the reason is that the
abstractions are too large or complex.

See John Volan's discussion about Ada's with'ing problem:

<http://bluemarble.net/~jvolan/WithingProblem/FAQ.html>

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Design By Contract

[Robert A Duff]

>In article <EFz0pD.E6n@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
>
>> I know you'll probably disagree, (and this is getting into Matt
>> Heaney territory), but I believe simplicity is innately,
>> universally, and uniformly recognisable by everyone. ...

Then how come not everyone in this thread seems to agree on what's
simpler than what?

- Bob

Re: Design By Contract

[Matthew Heaney]

In article <EG9Eo4.318@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>>In article <EFz0pD.E6n@syd.csa.com.au> nospam@thanks.com.au (Don
Harrison) writes:
>>
>>> I know you'll probably disagree, (and this is getting into Matt
>>> Heaney territory), but I believe simplicity is innately,
>>> universally, and uniformly recognisable by everyone. ...
>
>Then how come not everyone in this thread seems to agree on what's
>simpler than what?

Exactly.  Read my previous post about the difference between a
neurophysiologist and a butcher: to the butcher, the brain is quite simple
indeed!

And that's precisely the issue.  Complexity depends on things _and_ people,
because everyone's interest is different.

Read Dealing with Complexity, by Carson and Flood, for a  good introduction
to the concepts.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Design By Contract

[Joerg Rodemann]

Don Harrison (nospam@thanks.com.au) wrote:
> The thing is, though, that the designer of the supplier class *intends* the
> client to see the structure of attributes in just the same way as the author
> of an Ada interface *intends* clients to see the structure of a value
> returned
> by a function.

> Exporting happens on a need-to-know basis. If clients need attributes for 
> any purpose (including efficiency tuning), then the supplier exports them. 
> If they don't, then the supplier keeps them hidden. Note that in the
> extreme 
> case of an attribute whose underlying class exports none of its attributes, 
> you have the equivalent to an Ada private attribute. That is, the Ada

I wonder what this is all about? In Ada as well as in Eiffel you have to
decide if you grant a client read, read/write or none access to any member
variables of an object. Certainly the syntax of the following implementations
differ --- and in this case tend to need a few more characters in the Ada
version. Although there is a slight difference: in Ada you arrange one
or more 'class' definitions in a package whereas the feature mechanism of
Eiffel reminds me a little bit of the friend declarations in C++. (Sorry if
I got this wrong, I just had a short glance at Eiffel yet.) 

But at least I do not recognize any fundamental difference between the
explicit declaration of a function and the possibility to use a member 
variable as if it was a function. (As far as I remember there is some
construct in Ada where a similar interpretation is used. Perhaps someone
else has a better memory than me...must have been digging up too many
memory problems in C++ lately ;-> ) I occurs to me that the differences
this thread is all about start from a slight difference in writing. (You
use more words to say this, so mine is better. As in

   while ( cond ) {                      while cond loop
      ...                     vs.           ...
   }                                     end loop;

Well, of course just my opinion

Yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Design By Contract

[Jon S Anthony]

In article <340bb873.0@news.uni-ulm.de> rodemann@mathematik.uni-ulm.de (Joerg Rodemann) writes:

> I wonder what this is all about? In Ada as well as in Eiffel you have to
> decide if you grant a client read, read/write or none access to any member
> variables of an object.

Exactly.

> Certainly the syntax of the following implementations differ --- and
> in this case tend to need a few more characters in the Ada
> version. Although there is a slight difference: in Ada you arrange
> one or more 'class' definitions in a package whereas the feature
> mechanism of Eiffel reminds me a little bit of the friend
> declarations in C++. (Sorry if I got this wrong, I just had a short
> glance at Eiffel yet.)  >

Yes, this pretty much sounds on target as well.


> But at least I do not recognize any fundamental difference between the
> explicit declaration of a function and the possibility to use a member 
> variable as if it was a function.

Agreed here too.

> this thread is all about start from a slight difference in writing. (You
> use more words to say this, so mine is better. As in

You've just hit the nail on the head, IOW, "much ado about nothing"...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Patrick Doyle]

In article <JSA.97Aug28172900@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
>
>>   - Strict enforcement of encapsulation while maximising visibility. Eiffel 
>>     offers a look-but-don't-touch view of object attributes. In Ada83,
>>     an attribute and its type has to be declared in the visible interface in 
>>     order for clients to see it's structure but then they can also update it 
>>     directly. If you declare its type as private, clients can't update it 
>>     directly but neither can they see its structure.
>
>Isn't that exactly the point?  Why should a client be able to see the
>actual structure, aka implementation????

  If you mean that Eiffel is letting the structure leak out by
providing access to data members, then that's not true.  The
Eiffel syntax for accessing a data member and calling a function
with no parameters is identical.

  So consider what we'd do in C++ to encapsulate a data member:
we'd provide an accessor function.  In Eiffel, the syntax to do
would look like this:

class GOOBER

feature {ANY}

  get_value : INTEGER is do Result := value end

feature {NONE}

  value : INTEGER

end

  Now, imagine if, for convenience, you could name the accessor
function the same name as the variable--the added word "get"
doesn't really add anything to the equation here.  What you'd
end up with is a class which would behave *exactly* like this
one:

class GOOBER

feature {ANY}

  value : INTEGER

end

  More importantly, consider the purpose of encapsulation: the
representation can be changed while the interface remains the
same.  That can happen here, too.  The above class could change
to use a DOUBLE for the representation of value:

class GOOBER

feature {ANY}

  value : INTEGER is do Result := double_value end

feature {NONE}

  double_value : DOUBLE

end

  This new class would act just like the old one as far as
clients are concerned.

  So in conclusion, no, revealing the data members in this
way does not break encapsulation.  Note, however, that this
relies on the Eiffel syntax whereby functions with no parameters
are syntactically the same as data members.

  To answer your question, the client may be able to see
the data members, but the client can't possibly *know*
that that's what's going on.  As far as any client knows,
it's dealing with an accessor function.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[Jon S Anthony]

In article <EFnK04.J43@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >Isn't that exactly the point?  Why should a client be able to see the
> >actual structure, aka implementation????
> 
>   If you mean that Eiffel is letting the structure leak out by
> providing access to data members, then that's not true.  The

No.  That's not what I'm saying.  I'm not commenting about the Eiffel
approach at all (which in any event has nothing much to offer over the
Ada approach here anyway - beyond certain personal preferences that
is).

>   So in conclusion, no, revealing the data members in this
> way does not break encapsulation.  Note, however, that this

No one claimed otherwise.

>   To answer your question, the client may be able to see
> the data members, but the client can't possibly *know*

This at least touches on my point and IMO, this is problematic.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Design By Contract

[Patrick Doyle]

In article <JSA.97Aug30145354@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFqDw0.3x7@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>>   I'm afraid I don't know what your point is.  But let me
>> ask you this: Do you think providing accessor functions is
>> OK?  If so, what's the difference between accessors and the
>> Eiffel approach?  If not, why?
>
>Yes, (of course) providing accessor functions is OK.  The differences
>here are so trivial as to not be worth arguing about.  Which is
>probably the most important point here.

  Yes, but enlighten me.  What are these trivial differences?  I
promise I won't laugh.  :-)

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design By Contract

[Robert Dewar]

Don says

<<  - Simplicity which enables developers to focus on designing rather than
    trying to remember language rules. A simplistic macroscopic comparison
    of Eiffel and Ada based on the number of validity rules suggests that
    Eiffel is about 50 times simpler than Ada.>>


Simplicity is a very slippery term, what do you mean:

Simplicity of the description
Simplicity of format definition
Simplicity of programming applications
Simplicity of implementation

These are nowhere *near* the same thing. For example, let's compare the
floating-point rules in C and Ada. Gosh, C is FAR simpler, look at all
those rules in annex G in Ada, not to mention the basic stuff in chapter
3. None of that nonsense in C, C is much simpler.

But suppose the task is: write portable numerical codes. Oops, now we are
in big trouble in C, and the task is far *more* complex, because now we
have no guarantees from the language, and either the task is impossible,
or involves all kinds of complex external configuration control.

It is helpful whenever you use the word simple or complex to say exactly
what domain you are talking about. I see all the time people playing the
game where they argue simplicitly in one of these domains, implicitly
appealing to people's agreement that simplicity in another domain is crucial.

Re: Design By Contract

[Don Harrison]

Robert Dewar wrote:

:Don says
:
:<<  - Simplicity which enables developers to focus on designing rather than
:    trying to remember language rules. A simplistic, macroscopic comparison
:    of Eiffel and Ada based on the number of validity rules suggests that
:    Eiffel is about 50 times simpler than Ada.>>
:
:
:Simplicity is a very slippery term, what do you mean:
:
:Simplicity of the description
:Simplicity of format definition
:Simplicity of programming applications
:Simplicity of implementation

It's perhaps more convenient to express this in terms of the opposite quality:
complexity. What I mean specifically is the complexity of relationships between
language features (including libraries) in terms of its impact on developing 
applications.

:These are nowhere *near* the same thing. For example, let's compare the
:floating-point rules in C and Ada. Gosh, C is FAR simpler, look at all
:those rules in annex G in Ada, not to mention the basic stuff in chapter
:3. None of that nonsense in C, C is much simpler.
:
:But suppose the task is: write portable numerical codes. Oops, now we are
:in big trouble in C, and the task is far *more* complex, because now we
:have no guarantees from the language, and either the task is impossible,
:or involves all kinds of complex external configuration control.

Yes, I agree there are problems in attempting to compare languages when
one provides a facility and another doesn't. In such cases, it's necessary 
to add appropriate hypothetical mechanisms to the one that lacks them to 
compare fairly. In the case of Eiifel, you would need to add certain standard 
and optional class libraries, for example, to compare it with Ada.

Even though my formula for relative complexity is macroscopic, I think it 
has a sufficiently objective basis to be of some interest. It does require
some more accurate data than I currently have at my disposal. In particular, 
I would like to know:

  How many distinct numbered validity requirements are there in:

    - The core language part of the Ada RM
    - Each Annexe of the Ada RM

What I mean is how many of these: RM 10.1.2(4), for example. (Examples should 
be omitted).

If you, or anyone is willing to supply this information, I'll post the formula
and a discussion of it.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design by Contract

[Robert Dewar]

Roger says

<<Ada would benefit (for some applications) from Eiffel's garbage collection.
Apart from that, Ada has quite satisfactory ways of doing what Eiffel
has to offer. Although I prefer Eiffel's simple class-centric model and its
more disciplined exception model, Ada is certainly very usable without these.>>

As has been often pointed out, this is not a language issue, there is nothing
in the design of Ada that prohibits garbage collection, and indeed some
though has been given in the design to making sure nothing stands in its
way (unlike the case with C or, to a somewhat lesser extent withy C++).

Indeed there is at least one Ada implementation (the Intermetrics
Ada-to_Java compiler) that provides garbage collection, and soon there
will be at least one more.

Re: Design by Contract

[Don Harrison]

Roger Browne wrote:

:"W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes:
:
:> Suppose Ada added Eiffel assertions and Eiffel added separate
:> compilation of specs.  Or even some sort of automated control that
:> prevented changing contract without special privilege.
:
:No change is required to Eiffel to enable project managers to keep a hold of 
:the specs whilst letting programmers loose on the implementation.
:
:Simply code the spec as abstract classes in separate (locked) files and let 
:the programmers write the concrete implementation in child classes.

I tend to think deferred classes are not the proper analogue of Ada package
specifications.

Ada package specs, unlike Eiffel deferred classes exist for every module, 
so a better analogue for this module concept may be the class short form.
Deferred classes (specifically, the type aspects of them) are more analogous 
to Ada abstact types, IMO.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 17192 bytes --]



Nick Leaton wrote:
> 
> Ken Garlington wrote:
> >
> > Nick Leaton wrote:
> > >
> > > 1) Additional effort.
> > > There is plenty of evidence that the cost of finding and fixing a bug
> > > early in the development process is much cheaper that fixing it later.
> > > Now *IF* DBC as a methodology produces earlier detection of faults, then
> > > this 'additional effort' is justified, as it is effort early in the
> > > development process.
> >
> > No, re-read the quote: It can't just produce earlier detection of
> > faults;
> > it must be _better_ at detecting them early than _all_ other available
> > alternatives. Otherwise, you're not using your resources effectively.
> 
> Wrong. You have to cost the resource. 

Which is exactly what I am saying! You have to assign a cost to DBC, and
compare
it to the alternatives.


> I am asserting
> 
> 1. It catches many bugs early. Evidence is personal experience and
> others
>    have posted the same.

This statement provides no guidance as to assigning cost. It catches
bugs "early" - but not earlier than analysis of the UML (a la Jezequel)
for example. Thus, if this were the only criteria, DBC would not be
the best alternative.

> 
> 2. It is not expensive adding in assertions. There is a huge overlap in
>    writting an assertion and producing a correct specification so it is
> not
>    wasted work.

"Expensive" is a relative term, and this statement provides no guidance
as
to the _comparison_ (vs. what baseline?) you are making. If you are
saying, "it is
less expensive than writing a poor specification," then we agree.
However,
DBC is not the only alternative to writing a good specification, nor is
writing a good specification the only factor in producing quality
software.

> You now have to say what ALL the other resources are and what the costs
> are
> in using them to justify your statement.

My statement is "you now have to say what ALL the other resources are
and
what the costs are in using the to justify the statement: DBC is the
best
alternative." I'm glad we agree on this point.

Remember, fellow debators: The affirmative (DBC) has the burden of
proof, not
the negative! See: the principles of (a) status quo and (b) inherency.

> 
> > Furthermore, if it detects 20% of the total system faults early, but
> > as a result there isn't sufficient resources to use other techniques
> > to find the resulting 80% that are left, then although you fixed the
> > 20% more cheaply than some other alternative, you have still delivered
> > a system with 80% of the faults remaining. So, coverage of the faults
> > by quantity is an issue as well as speed.
> 
> But you assume that the other resources will find the faults within your
> resource budget. What if you haven't the resources, which is your
> argument against
> DBC? Can you fit a quart in a pint pot?

No, no, Nanette! I make no such assumption. YOU have the burden of proof
here.
I don't have to _assume_ anything!

You're repeating my argument exactly. You _can't fit a quart in a pint
pot.
Therefore, DBC must not only be effective; it must the the _most_
effective
of the alternatives.

> You have assumed that using DBC uses up resources at such a rate that it
> stops you producing product.  Implementing DBC does not take up huge
> resources at the coding stage. 

"Huge..." what a (relative) concept!

> At the design stage you should be
> specifying what you want to have happen at the level required to
> implement DBC, so there is no additional resources going to waste here.

Now you have made a statement you will have to defend vigourously. This
statement says that DBC takes _zero_ resources more than the
alternatives.

> 
> DBC is cost effective

Prove it!

> as a method of producing quality code, and does
> not take major resources

Post some numbers!

> to achieve. Having a compiler help you makes a
> big difference, which is where the Eiffel part comes into play.

"big"... compared to what!

> 
> > Finally, even if DBC discovers 95% of the faults, but the remaining 5%
> > are the most serious, you still have a problem. So, the ability to
> > detect the most serious faults, as well as the quantity and speed, must
> > be evaluated vs. _all_ alternatives.
> 
> All programmers reading this, if offered a method that found 95% of bugs
> the first time they executed a particular path in their code, would
> welcome it. It leaves them with more resources to work on the hard 5%

Not if the effort to get the 95% fails to get the 5%.

By the way, _safety-critical_ programmers do not agree with this
statement.
I will gladly release software with several minor problems in order to
make sure I have found and corrected the critical problems.


> 
> > That's the common fallacy of the Eiffel advocate argument: "It's better
> > than what I was doing, so go use it." However, was what you were doing
> > before the best approach (excluding Eiffel)?
> 
> I was not necessarily using the ideal approach before, but I haven't
> made this statement.

Actually, you have. You just don't realize it.

> I have found in practice, that DBC as a method
> works. You have to propose other ways of achieving what DBC achieves,
> with less effort.

Again, it's not my argument to make. You have the burden of proof.

2+2=4, therefore God exists! Dispute it!

> 
> > > 2) Time spent else where.
> > > Is this the case? Some of it may be, but I believe if you cannot be
> > > rigourous about what your software is trying to do, by writing
> > > assertions, then you are unlikely to produce a quality system.
> >
> > Bad argument. You haven't proven that "writing software rigorously"
> > is _best_ done by "writing assertions." For that matter, you haven't
> > shown that the "writing" (coding?) phase is the most critical with
> > respect to producing a quality system. Consider, for example, that
> > there are approaches that can generate software with no manual coding...
> 
> Eh? (the last sentence)

Welcome to the world of autocoding! See http://www.ise.com for one
of many examples.

> 
> > > The
> > > effect of writing assertions overlaps with the design process. It is not
> > > wasted time, it just comes under a different heading. If your design
> > > process listed the assertions in the specification, would implementing
> > > them be a waste of effort?
> >
> > Yes, quite possibly, implementing assertions in the code may be both
> > ineffective and counter-productive, compared to other approaches,
> > depending
> > upon circumstances.
> 
> What other approaches? What evidence do you have? (PS I have read your
> critique)

What other approaches are there to quality software? Let us list the
ways:
Formal reasoning, use cases, patterns, cleanroom, N-version programming,
PSP, power CASE, FMET, autocoding, reuse... (everbody sing along!)

Without quantitative measures, you're preaching a religion, not
evaluating
a technique.

> > > 3) Simple software.
> > > You bet. The simpler the better. Occams Razor rules. Now here there is a
> > > split between DBC a la Eiffel and DBC, say in C++. In Eiffel it is
> > > simple.
> >
> > "Simple software" is not synonymous with "easiler to write code." The
> > question
> > is: is software with assertions less complex than software without
> > assertions.
> > Based on measures of merit such as lines of code, paths, etc. the answer
> > is
> > "no".
> 
> Given a complex solution and a simple solution to the same problem, the
> simple solution is the one with merit. Period.
> 
> If you don't assert your software, then you have to write test code to
> test the same assertions (specification) in order to satisfy yourself it
> is correct.

Test oracles, debugger scripts, reliability models, structural testing,
etc.
There is a whole world of means to "satisfy yourself it is correct"
beyond
writing test code (who does this sort of trash anymore, anyway? We
haven't
done it in at least 5 years!).

> DBC on your measures of merit stated above, when you take the whole
> system into account will be better.

Only if you're comparing it to an obsolete alternative (as you did).

> 
> > > In C++ it is hard, particularly with inheritance of assertions.
> >
> > Again, this is the fallacy of the argument. Why are you comparing Eiffel
> > to
> > C++? (The second fallacy: Why are you comparing languages when
> > discussing
> > DBC as a methodology?)
> >
> > > One common theme from Eiffel practitioners is their support for DBC.
> > > Why? They are simple to write.
> >
> > As a motivation, consider this:
> >
> > Here is a simple assertion:
> >
> > "The sun is hot."
> >
> > Now, put this in your code as a comment. Is the code simpler as a
> > result?
> > Put it in 1,000 times (simple to do with a text editor, right)? Is
> > the code simpler as a result?
> >
> > > Assertions affect timing in safety critical systems.
> > >
> > > Firstly it depends on the implementation. It is easy to envisage a
> > > system where the assertions are redundantly executed. But you would only
> > > want to do that if you were running with faulty software ?!*^�%
> > >
> > > I also find it worrying that systems are being used for safety critical
> > > apps where there is the possibility of a race or deadlock to occur.
> >
> > Then you would agree that it is critical to test systems to ensure that
> > such possibilities are not present, correct? And so, doing things which
> > mask the presence of such errors during testing are bad, right? So,
> > you agree with my argument!
> >
> > If we are to assume the system is implemented correctly, why bother with
> > assertions as a means to validate system correctness!
> 
> Because you want to be sure it is implemented correctly!

But you already assumed the system is implemented correctly!
Why are you now unsure!

> 
> > I am always amazed when people don't grasp this. It's not that the
> > system is designed intentionally to permit race or deadlock; the concern
> > is making sure that you didn't _inadvertantly_ do this! It's like
> > saying:
> >
> > "I also find it worrying that systems are being used for safety critical
> > apps where there is the possibility of faults to occur." as an argument
> > for not testing at all!
> >
> > > Compilation problems.
> > > These can occur in any system as you are aware. From discussions with
> > > some of the people involved in writting Eiffel compilers, the enabling,
> > > disabling of assertions has a very trivial implementation, which is very
> > > unlikely to go wrong.
> >
> > Define "unlikely". As I note in the paper, no evidence has been provided
> > regarding this issue. My argument is that, the more complexity added to
> > the software, the more likely the introduction of a fault due to a
> > compiler
> > bug.
> 
> Do some thinking about how you would implement DBC if you were a
> compiler writer. Consider how to enable, disable the assertions. Is this
> a 'hard problem' to solve?

Yes, based on real experience with real compilers.
(I know that real experience doesn't compete with theory, but I find it
comforting nonetheless :)

> 
> > Would you be willing to use a safety-critical system if the engineer
> > said,
> > "Well, we didn't actually test the code we fielded, but we tested code
> > that was pretty much the same."?
> 
> No. I would do the testing. I'm not stupid.

So much for zero cost DBC! You now get to do the testing twice.

Compare to just _one_ alternative: coding the assertions in a debugger
script using
real-time non-intrusive monitoring. Since the assertions are outside the
code, you can (1) test just once (since the assertions do not affect the
code) and (2) have the assertions reference objects not in the code
(e.g.
values in the external environment not directly available to the code
under test). These assertions can be generated from a test oracle hooked
up to a UML (or other notation) model of the system, if you like. They
can be incorporated into a "short form" of the spec for review. So,
compared
to DBC, they do the same thing (assuming you were not going to have
the assertions execute during production) and cost less. We do this
today,
so we know it works. 

Since we agree on comparitive cost as the criteria, you now have to show
why this
alternative costs more. (The negative has introduced an alternative
plan, with
no inherency! Incredible!)


> > > It has also be extensively tested in the field by
> > > end users.
> >
> > Insufficient. How many years had the Ariane IV IRS been flown before it
> > was installed in the Ariane V?
> 
> Agreed. But give yourself the choice.
> 
> a) Tested by software engineers.
> 
> b) Tested by software engineers and lots of users.

Invalid. Show that the Eiffel compiler meets the first clause of (a),
and to what extent. The true choice is:

a) Tested by software engineers to a known standard.
b) Used in various domains (not your own), and tested to some unknown
standard.

I'll be taking "a", please!


> 
> > > Do you trust your compiler? If not, you shouldn't be writing safety
> > > critical software with it. Period.
> >
> > Irrelevant. Much like saying, "I trust my development team, so I won't
> > test their products." Blindly "trusting" any part of the development
> > process is extremely dangerous.
> 
> See you argument above, I'll quote it again
> 
> * If we are to assume the system is implemented correctly, why bother
> with
> * assertions as a means to validate system correctness!
> 
> This is why assertions are good. You don't blindly trust.

Interesting that you quote your own argument to reinforce your own
argument! You are the one who assumed the system was implemented
correctly, remember? I was the one who pointed out this was a bad
idea.

Glad we could agree that we should not assume the compiler is
implemented
correctly!


> 
> > > Next I find some of the logic of your arguments here very weak.
> > > Paraphrasing. We have trouble testing safety critical systems, but we
> > > will use them anyway.
> >
> > If you have trouble with the argument, "real-world safety critical
> > systems
> > are difficult to develop and qualify," then I recommend you stay away
> > from all real-world safety critical systems.
> >
> > More to the point, the "paraphrasing" misses the argument. Here is
> > a better summary. "Keep it simple, stupid. Don't add complexity to the
> > product or the process unless it provides the best payoff vs. all
> > alternatives. Furthermore, _all_ alternatives have risks as well as
> > benefits; ignore anyone who says otherwise as a religious fanatic."
> 
> I'll agree with this point. The disagreement between us is over DBC
> being an aid to improving the process. From practical experience, I
> believe it does.

Without quantification, all we can do is bow our heads and pray at this
point.

Leaving the telephone off the hook is also an aid to improving the
process (this is a real result of a real study). Compare the costs
and benefits of this vs. DBC.

> I don't think that you have backed your arguments up with enough facts
> to justify your position.

Fortunately, I'm not the one advancing the assertion that DBC is the
best alternative. If I were, I would be worried.

> Now that is not saying your wrong, but part of
> the reason for havin a vocal discusion on the point is DBC advocates
> have taken an theory on board that they believe to be correct.
                                          *******

I "believe" that you have summarized my problem with your argument
quite neatly.


> As with
> all discusion on theory, you have to come up with examples that
> contradict, or a better theory.

Actually, no. The burden of proof is on the group advancing the
claim. All I've said is that you haven't proved your claim.

But, just for fun, I did give you a cheaper alternative, so you
can look at that if you want.

> The contradictions either show up
> missing parts of the theory, in which case it is improved, or you come
> up with a new theory which is better.

Actually, no. I think you dropped a few steps in the scientific method
(somewhere between "pose a hypothesis" and "accept or reject
hypothesis").

> Since you have strongly held
> views, I want find out what they are, since they might improve mine and
> others knowledge.

What makes you think I have strongly held views? For that matter, what
relevance is the _strength_ of the views? Sounds suspiciously like a
religious argument, which I find boring.

> 
> > > Hmmm.
> > >
> > > >   http://www.flash.net/~kennieg/ariane.html#s3.3
> > > >
> > > > There are approaches that can avoid such costs, particularly those of
> > > > 3.2.2 and 3.3 (by not requiring object code modification). 3.1.6 can
> > > > be mitigated through the use of techniques that minimize cost (e.g.
> > > > automated structural testing analysis).
> >
> > I note you didn't respond to this part. Hmmm indeed!
> 
> I'll look it up and reply.
> 
> >
> > In any case, I'm going to have a wonderful Labor Day, hope you have the
> > same. Just don't build any safety-critical systems that I might end
> > up using, OK?
> 
> Your pension probably depends on it. ;-) As I do when I go flying in
> Norfolk, lots of your products wizzing around the sky there.
> 
> --
> 
> Nick

Critique of Ariane 5 paper (finally)

[AdaWorks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]


From: Richard Riehle
To:   DBC Discussion

Design by Contract (DBC) is a powerful idea.  It is more powerful than
the notion of assertions, alone. Although, I believe assertions can
be an important aspect of DBC, restricting our discussion to assertions
probably leads us to taking too small a view of DBC.    

I think DBC includes:

  1) Explicit separation of the contract from the implementation
  2) Ability to maximize contract violations at compile time
  3) Clear statement to client of the contract of what is promised
  4) Conditions under which the contract would be violated
  5) Conditions under which the contract would be broken
 
�There are probably others.

Ada supports all five of these in very important ways. In particular,
Ada provides the superb support for 1), separation of contract
from implementation through the specification/body model for packages.
Number 2) is also a strong point of Ada because the language is designed
with exactly that goal in mind.  

To expand a little on item number 2). No programming language is
more effective at supporting this than Ada. The package specification 
rigorously defines the profile of every public method (subprogram) thereby 
permitting strict compile-time checking on any call; the scope and
visibility rules, draconion in the view of some programmers, prevents
a client from falling into some ambiguity trap,  concientious use of
named association further ensures compile-time checking, the type
model guarantees that collisons between incompatible data elements
will not occur, and the accessiblity rules raise the probability that
pointer-related errors will be caught at compile time.

Number three implies both traceability and understandability. This is
well-supported in Ada through both the scope and visibility rules and
the separation of the contract into a visible part and a non-visible
part.  The addition of private children in Ada 95 allows us to improve
upon this even further.  Ada does not take a back seat to any other
language on this point, even though Eiffel also supports this 
very well.

The fourth and fifth points are closely-related yet subtly different.
For this discussion, we consider them together.  Ada has taken a more
conservative view of the contract than some languages.  The type-safe
model does include an invariant for the type.  It also includes a
simple pre- and post-condition in the form of range constraints. While
this is not as sophisticated as explicit assertions, it works quite
well when coupled with the other rules for subprogram invocation and
visibility control.  

All of that begin said, I do like the idea of adding assertions to
Ada as additional support for 5) & 6).  It is important to realize,
though, that an assertion may be incorrectly stated more easily than
one would like.  A wrongly-formed assertion might be more of a problem
than no assertion at all.  

We would probably profit from exploring the DBC notion in greater
depth.  But the benfits from that exploration will be greatest if
we define it a higher level of abstraction than simple assertions.
I think Bertrand would agree with this "assertion".  
I hope others will.

Richard Riehle
AdaWorks
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815

                    P.S. My News Server is acting funny right now so
                         it is difficult for me to respond directly to
                         postings until it gets fixed.
                                               RR

 
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Critique of Ariane 5 paper (finally!)

[Marin David Condic, 561.796.8997, M/S 731-96]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>Note incidentally tha DBC seems to be a slippery character in this argument.
>At one end it is a very specific technique embodied in syntax in the tools
>being used, and at the other (see quoted paragraph above), it is referred
>to as though it is little more than the idea of saying what components of
>a program should do.
>
>Well of course if we take the second view, then it is certainly true that
>far more programs meet this criterion, which has by now been watered down
>to little more than "you should comment your programs properly".
>
>However, even with this watered down viewpoint, not all reliable programs
>meet the criterion. From time to time, there have been people holding the
>strong position that code should be self-documenting and that comments or
>documentation of any kind of the code is evil, becuse it could be wrong.
>
>I personally think this viewpoint is ludicrous and off the wall, BUT
>I would not for a moment claim that people following this viewpoint cannot
>produce reliable software (I know of counter examples -- yes, they surprise
>me, but the fact is that competent people can do almost anything with almost
>any tools, so general rules of good practice are almost never absolute).
>
    How about this: Build a random code generator which fills the
    first hundred or so words of memory with instructions. Execute
    those instructions. If the instructions output the string "Hello
    World!" once and then halt, the code has met the requirements and
    the image is to be saved for future executions.

    No DBC. No Object Oriented Design/Programming. No structured
    programming. No code walk-throughs. No methodology. No nothing. Yet
    I'd bet that a program could be constructed this way and be 100%,
    double-your-money-back-guaranteed reliable (Barring "Acts Of God"
    such as power outages! But then, that's a *hardware* reliability
    problem.:-) Software doesn't rot, rust or wear out, so the MTBF
    can be considered infinite.

    In other words: If you can think of only one way to solve a
    problem, then clearly you have not thought about it long enough. A
    jingoistic support of some method or technique as "the only"
    method or technique that can produce reliable, safe, "good"
    software is not particularly helpful. It also ends up insulting
    the folks who *do* produce reliable, safe, "good" software using
    other techniques as if they don't know their business.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
  "I saw a bank that said "24 Hour Banking", but I don't have that much time."
        --  Steven Wright
===============================================================================

Critique of Ariane 5 paper (finally!)

[Ken Garlington]

I've put what I hope is my final version of my critique of the Eiffel
Ariane 5 paper at:

  http://www.flash.net/~kennieg/ariane.html

I hope that this gets referenced from the Eiffel web site, to provide
some balance to the original article. Thanks to everyone who helped out.

Readers may also be interested in the Meyer article on Java at

  http://www.cm.cf.ac.uk/CLE//volume97/18338

The discussion is interesting in that Meyer (a) criticizes Java for not
being used on large projects (whatever happened to unfair criticism of
new languages? :), (b) uses the Ariane 5 paper as justification for the
need for assertions, and (c) notes that Eiffel supports C++ interfaces,
with Java VM support coming soon (why wait when Intermetrics already
supports Ada applets running on the JVM? :)

Re: Critique of Ariane 5 paper (finally!)

[Juergen Schlegelmilch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]


On Wed, 06 Aug 1997, Bertrand Meyer <Bertrand.Meyer@eiffel.com> wrote:
>I am "willing to guess" anything but guesses are not very
>enlightening. More to the point, however, you may want to read
>the article by Alan Radding in Software Magazine (not IEEE
>Software), July 1997, pages 51-54. It is entitled
>"Tool Immaturity Tempers Java" and begins: "With the pack of
>vendors offering Java-based development tools and developers
>clamoring for them, you'd think everyone have Java projects
>underway. They don't. The lack of mature tools and standards
>is keeping most companies in exploration mode." The article
>quotes Judith Hurwitz from the Hurwitz Group as "counsel[ing]
>developers not to expect a robust, industrial-strength Java
>development environment for about three years". It adds
>"In addition, Java compilers are slow", quoting Mitch Kramer,
>a senior analyst with Patricia Seybold Group. Jeffry Borror,
>director of information technology at Daiwa Securities America
>is quoted as saying "Java hasn't stabilized as a language, and
>the tools still lack many features". Etc.

If you have a look at Eiffel, the situation is similar: Today
we see the third version of the language, and there are still
subtle points under discussion in this group. Also, it took
Eiffel vendors about 10 years to offer mature tool support, and 
the compilers are still not the fastest (although much improved).

So, don't disqualify a language because it is young.

  J�rgen Schlegelmilch
-- 
+-----------------------------------------------------------------------------+
 Dipl.-Inf. Juergen Schlegelmilch                 University of Rostock
 email: schlegel@Informatik.Uni-Rostock.de        Computer Science Department
 http://www.informatik.uni-rostock.de/~schlegel   Database Research Group 
 Tel: ++49 381 498 3402                           18051 Rostock 
 Fax: ++49 381 498 3426                           Germany
+-----------------------------------------------------------------------------+

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Robert Dewar wrote:
> 
> [Quoting Ken Garlington]
> 
> !!! The discussion is interesting in that Meyer (a) criticizes
> !!! Java for not being used on large projects
> !!! (whatever happened to unfair criticism of new languages?
> 
> [Robert Dewar]
> 
> > Hmmm! I guess he does not consider the Corel office suite large!!!
> > Or perhaps simply does not know about it
> 
> It would be difficult not to know about it, as it gets hammered
> over and again by Java proponents (along with Java
> tools themselves) as the example of completed Java development,
> to the extent that one may wonder whether there is any other.

How many large-scale projects need to be performed before evidence
of scalability is established?

What was the standard set for Eiffel, for example? How long after
Eiffel's introduction was this standard met?

> 
> > (actually a surprising number of
> > large projects are being done in Java, I would be willing
> > to guess that at any program size, the use of Java eclipses
> > the use of Eiffel by a very wide margin).
> 
> I am "willing to guess" anything but guesses are not very
> enlightening. More to the point, however, you may want to read
> the article by Alan Radding in Software Magazine (not IEEE
> Software), July 1997, pages 51-54. It is entitled
> "Tool Immaturity Tempers Java" and begins: "With the pack of
> vendors offering Java-based development tools and developers
> clamoring for them, you'd think everyone have Java projects
> underway. They don't. The lack of mature tools and standards
> is keeping most companies in exploration mode." The article
> quotes Judith Hurwitz from the Hurwitz Group as "counsel[ing]
> developers not to expect a robust, industrial-strength Java
> development environment for about three years". It adds
> "In addition, Java compilers are slow", quoting Mitch Kramer,
> a senior analyst with Patricia Seybold Group. Jeffry Borror,
> director of information technology at Daiwa Securities America
> is quoted as saying "Java hasn't stabilized as a language, and
> the tools still lack many features". Etc.

Weren't some of these same complaints made about Eiffel in it's
early years? (I seem to remember recently seeing some posts to
this effect, in fact.) I know they were made about Ada (I made
some of them :), and Ada has certainly shown that it can be
used in some very large-scale projects (1M+ SLOCs), that
it can be reused/ported successfully, etc.

It just seems a little premature to bash Java simply because
of lack of use. As I said about Eiffel:

"There does not appear to be any evidence that DBC/Eiffel
has been successfully used in a system like the Ariane IRS,
much less that it produced significantly improved safety
or reliability. By itself, this is not particularly
damaging: All new ideas have to have a first user."

> 
> On portability see also the article extracts (from
> ComputerWorld and IEEE Computer) at
> http://www.eiffel.com/general/news.
> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> Web: http://www.eiffel.com, with instructions for free download
> == ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Another note regarding the Meyer attack on Java:

The portability of Java is questioned, primarily by reference
to a trade article where Microsoft has "declared war" on Sun
over Java -- the implication being that Java will not be available
on Microsoft OSs (e.g. Windows). I'm not sure that the cause and
effect is particularly well established, but coincidentally I
read that, in the new Apple-Microsoft collaboration, the two
parties have agreed to work to provide more Java support on
Apple products. Apparently, the "war" is more Microsoft vs.
Sun than Microsoft vs. Java.

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

It's impossible to have a meaningful discussion
if one's arguments are distorted and misquoted.

Ken Garlington wrote:

> Another note regarding the Meyer attack on Java:

There is no such thing as a "Meyer attack on Java".
Read my postings and articles and you will see that
if they "attack" something it is the idea that Java
is the language to replace all languages. That's
rather different.

> The portability of Java is questioned [in an article
> at http://www.eiffel.com/general/news] primarily by reference
> to a trade article where Microsoft has "declared war" on Sun
> over Java -- the implication being that Java will not be available
> on Microsoft OSs (e.g. Windows).

There is no such implication, which would be foolish.
Microsoft has said they would not support the Java Foundation
Class libraries. This does not mean they are not making
Java itself available; but it does break the myth of total and
automatic Java portability.

There is enough room for controversy in what people actually
write not to create artificial disputes about what someone
else believe they think. This is just a waste of everyone's
time.
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> It's impossible to have a meaningful discussion
> if one's arguments are distorted and misquoted.
> 
> Ken Garlington wrote:
> 
> > Another note regarding the Meyer attack on Java:
> 
> There is no such thing as a "Meyer attack on Java".
> Read my postings and articles and you will see that
> if they "attack" something it is the idea that Java
> is the language to replace all languages. That's
> rather different.

I stand corrected. I should have said: "Another note
regarding the Meyer 'attack' on Java being the language
to replace all other languages..."

This "attack" was predicated (in part) on the following
points, which I challenged:

1. That there was not enough evidence that Java could
scale to large projects. I questioned whether this
was really a fundamental obstacle, since there are
also concerns about the scalability of Eiffel. Furthermore,
your own statements about the lack of language use not
being a sufficient argument for rejecting it (e.g.
Eiffel for real-time safety-critical avionics) seems
to shed doubt on the value of your contention.

2. That using the Ariane 5 example to "prove" that Java
was flawed due to a lack of built-in assertions was,
itself, flawed. This is discussed in more detail in
http://www.flash.net/~kennieg/ariane.html.

I assume there is no response to these rebuttals?

> 
> > The portability of Java is questioned [in an article
> > at http://www.eiffel.com/general/news] primarily by reference
> > to a trade article where Microsoft has "declared war" on Sun
> > over Java -- the implication being that Java will not be available
> > on Microsoft OSs (e.g. Windows).
> 
> There is no such implication, which would be foolish.
> Microsoft has said they would not support the Java Foundation
> Class libraries. This does not mean they are not making
> Java itself available; but it does break the myth of total and
> automatic Java portability.

Again, you are correct: I should have said "the implication being
that Java Foundation Class libraries will not be available on
Microsoft OSs (e.g. Windows)."

Today's paper had more information about Microsoft and Java
(in the context of the Apple deal):

"Sun, along with IBM, Oracle, and other industry players, has
been promoting Java as a new operating system that would
succeed Microsoft's Windows as the future industry standard
as more computing power is expected to occur over networks,
instead of the PC desktop.

"Not surprisingly, Microsoft has been resisting those efforts.
It has embraced Java as a programming language that software
companies can use to write programs that run on Microsoft's
Windows PC operating system software."

So, with respect to Java as a portable OS, I believe you are
correct. However, with respect to Java as a programming
language, it's unclear to me whether there will be a single
internationally accepted standard or not. Are all
Eiffel implementations from all vendors standardized? How is this
determined?

The article goes on to discuss Microsoft and Apple collaborating
on Java implementations. I note that the Eiffel comments on this
article mentions that Eiffel is available on "Windows NT, Windows 95,
Unix (a dozen different platforms), Linux and VMS...." Is an Apple
implementation in the works?

> 
> There is enough room for controversy in what people actually
> write not to create artificial disputes about what someone
> else believe they think. This is just a waste of everyone's
> time.

I apologize if my overly-simplified summary misled anyone.

> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> Web: http://www.eiffel.com, with instructions for free download
> == ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Ken Garlington wrote:
> 
> The article goes on to discuss Microsoft and Apple collaborating
> on Java implementations. I note that the Eiffel comments on this
> article mentions that Eiffel is available on "Windows NT, Windows 95,
> Unix (a dozen different platforms), Linux and VMS...." Is an Apple
> implementation in the works?

After sending this, I realized that again I may have oversimplified
Mr. Meyer's statement in this area. This is the full quote:

"Last week's story showed the limits of Java's promise of openness.
With the rift between Microsoft and Sun, the promise of
portability also evaporates. 

"Eiffel, and in particular ISE Eiffel, provides one of the very few
truly portable development environment available in the software
industry. The same set of tools and libraries runs across Windows
NT, Windows 95, Unix (a dozen different platforms), Linux and
VMS with no need for source code change. In particular: EiffelVision
is a fully portable graphical library; and the EiffelNet library
supports multi-platform client-server development, with fully
transparent object exchange. The recently released DAIS-Eiffel
CORBA implementation from ICL Inc. supports interoperability
with other platforms and languages. ISE's C and C++ interface is
one more tool supporting openness and portability.

"For corporate customers who are looking for an open and portable
solution available today, rather than promises subject to the
conflicting requirements of companies that fiercely compete with
each other, the choice is clear."

I hope this corrects any misconceptions that might have occured
from the earlier summarized quote.

Re: Critique of Ariane 5 paper (finally!)

[Don Harrison]

Ken Garlington wrote:

:This "attack" was predicated (in part) on the following
:points, which I challenged:
:
:1. That there was not enough evidence that Java could
:scale to large projects. I questioned whether this
:was really a fundamental obstacle, since there are
:also concerns about the scalability of Eiffel. 

It's also said that Goody Proctor is a witch. :)  However, even though the 
inhabitants of Salem readily believed it, saying so didn't make her one. 
(Apologies to Arthur Miller, author of "The Crucible". BTW, the recent film 
by the same name is well worth watching for any student of mass hysteria.)

I'm still waiting to see a valid argument why Eiffel software is not scalable. 
I don't have the time or desire to argue why it *is* scalable (and there are 
others better qualified to do so), but two contributing factors stand out:

1) The existence of configuration "modules" which support framework (cluster)
   hierarchies - this makes configuration scalable.

   See the section titled "Scalability" in Walden and Nerson - "Seamless 
   Object-oriented Software Architecture" P. 18-19.

2) The ability to encapsulate high-level abstractions in high-level classes 
   using standard design patterns - this makes abstraction and contracting 
   scalable.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

I am deeply appreciative to  Ken Garlington for his
willingness to moderate his earlier restatements
of my positions. This greatly facilitates the discussion
and shows openness of mind. Thanks.

On the crux of the issue, I have looked at his messages
and really don't have much to add to what has been written
before, especially the Jezequel-Meyer paper on Ariane
accessible from http://www.eiffel.com, the ISE
"news items of the week" at the same address, and
of course "Object-Oriented Software Construction,
2nd edition" where the Design by Contract ideas
are developed in detail.

As convincingly as I could, my colleagues and I
have explained: why in our view
software technology crucially requires the systematic use of
Design by Contract; why Design by Contract is a
necessary condition to avoid more Ariane-like failures;
and what is missing in this respect in such approaches
as Java, Ada, C++, IDL.

Ken Garlington, and others such as Robert Dewar, disagree
at least in part. I find it hard to understand their position,
but there is now enough published arguments on both sides to
enable every reader to make up his mind.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Bertrand says

<<As convincingly as I could, my colleagues and I
have explained: why in our view
software technology crucially requires the systematic use of
Design by Contract; why Design by Contract is a
necessary condition to avoid more Ariane-like failures;
and what is missing in this respect in such approaches
as Java, Ada, C++, IDL.>>

Your argument at *best* says that DBC might have been a *sufficient*
condition for avoiding the Ariane failure. Even there, it seems over-facile
and rather academic, and does not seem to understand fully the exact nature
of the Ariane problem.

But to make the jump from sufficient to necessary is completely without basis,
and can only be regarded as advertising puffery. To prove this you would have
to show that no other method can succeed, an impossible burden.

You have to be very careful in not making excessive claims, especially
when it is clear that you are not disinterested in the claim!

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Professor Robert Dewar wrote that my argument

> seems over-facile and rather academic 

Wow! But I'll choose to take "academic", coming from
a .edu address, as a compliment. And "over-facile"
might refer to how easy the basic ideas of Design
by Contract are to teach and implement.

He adds that what he calls my "jump from sufficient to
necessary" 
 
> can only be regarded as advertising puffery.

Advertising puffery! Delightful choice of words.
Now this is a solid technical rebuttal. But here is the
explanation:

> [I]t is clear that you [i.e. me, BM] are not disinterested
> in the claim!

OK, finally things are clear. When everything else fails, resort
to questioning the other person's integrity: I have a vested
interest in seeing Eiffel succeed -- that explains it all.
(Doesn't explain, though, why so many other contributors have
expressed agreement with the analysis of the Jezequel-Meyer
Ariane paper and support for Design by Contract.)
 
This is a slippery path to follow since very few people
can claim to be "disinterested". So are Robert Dewar and
I  going to spend the next three months arguing who is the most
unbiased? No, no and no. I won't be dragged down to that level
and will just assume that the line quoted above was a
regrettable slip of the pen. 

The "necessary" condition is simple: you won't get reliable
software unless you take care to associate specifications --
contracts -- with software elements, especially reusable
components. You can then use these contracts to build
the software, to document it, to validate it statically,
to test it (if you have support for run-time monitoring,
as in Eiffel), to control the proper use of inheritance,
to discuss the software within the software team as well
as with management, customers, users and regulatory agencies.
Anyone who has used the approach knows that it dramatically
improves the quality of the product and the process.
And it's not even an expensive technique.

No one ever said Design by Contract was "sufficient".
My "Object-Oriented Software Construction, 2nd Edition"
(Prentice Hall) has a 9-page section (11.14, pp. 398-406)
discussing its limitations. But to encourage developers of
mission-critical software to ignore this powerful tool is
irresponsible. How many more Ariane-like failures do we
need?


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> (Doesn't explain, though, why so many other contributors have
> expressed agreement with the analysis of the Jezequel-Meyer
> Ariane paper and support for Design by Contract.)

How many of them build safety-critical real-time systems? None
who support DBC have indicated experience in this field. Thus,
my explanation is simple: they have insufficient experience
to judge the likely pitfalls in the application of DBC to a domain
they (and, I assume, you) don't understand.

Your case seems to be somewhat less strong among the actual
practitioners in the field. Coupled with the apparent lack
of Eiffel applications in the domain under discussion, your
appeals to authority (random Eiffel users on Internet?) aren't
all that compelling.

> This is a slippery path to follow since very few people
> can claim to be "disinterested". So are Robert Dewar and
> I  going to spend the next three months arguing who is the most
> unbiased? No, no and no. I won't be dragged down to that level
> and will just assume that the line quoted above was a
> regrettable slip of the pen.

On the other hand, _I_ have absolutely no vested interest in
either promoting Ada or attacking Eiffel; nor do I have any
interest in defending the Ariane 5 team. I do have an interest
in using new technologies in the domain in which you have
taken a sudden interest, and would like to understand how
it could help. However, my concerns have been uniformly
unaddressed through any sort of technical argument.

I notice that both you and Mr. Jezequel have a strong desire
to uncover "vested interests." When I first joined this
discussion, he assured me that my job as a software test
engineer would not be eliminated by a switch to DBC. Since
I'm not a software test specialist, this was a strange
statement to make, to be sure. :)

So, other than some perceived bias of practitioners against
"the next big technology." as I believe you indicated in
a previous post, what is the bias that practitioners such
as myself, Mr. Kohl, and Mr. White have against DBC (other
than the obvious one -- we won't use a technology whose
authors are so emotionally involved in their quest that
they are insulted by the mere suggestion of contrary views)?

> The "necessary" condition is simple: you won't get reliable
> software unless you take care to associate specifications --
> contracts -- with software elements, especially reusable
> components. You can then use these contracts to build
> the software, to document it, to validate it statically,
> to test it (if you have support for run-time monitoring,
> as in Eiffel), to control the proper use of inheritance,
> to discuss the software within the software team as well
> as with management, customers, users and regulatory agencies.
> Anyone who has used the approach knows that it dramatically
> improves the quality of the product and the process.
> And it's not even an expensive technique.
> 
> No one ever said Design by Contract was "sufficient".

Other than youself, in your Ariane 5 paper.

Perhaps it's a problem of the English language; but "probably yes"
certainly translates as "sufficient" in my understanding.

> My "Object-Oriented Software Construction, 2nd Edition"
> (Prentice Hall) has a 9-page section (11.14, pp. 398-406)
> discussing its limitations. But to encourage developers of
> mission-critical software to ignore this powerful tool is
> irresponsible. 

This is really the true irony. Several practitioners have
invested a great deal of Internet time _not_ ignoring this
technology. We have tried to understand why it would help in
our domain; have tried to draw the Eiffel experts into a
technical discussion of its strengths and weaknesses, and
have generally been told

  -- we don't understand our own products
  -- we don't understand software engineering
  -- we are biases against new ideas

I wonder why there aren't more Eiffel projects in this
domain? :)

Mr. Jezequel and Mr. Meyer have both indicated they
have no interest in pursuing any discussions on this
subject. Isn't this the same as irresponsibly discouraging
the use of DBC?

>How many more Ariane-like failures do we
> need?

No more. This is why we need a balanced budget immediately!
(Why not? If I don't have to show that a balanced budget
would have prevented the problem, it's an equally important
claim!)

> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> Web: http://www.eiffel.com, with instructions for free download
> == ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Bertrand said

<<The "necessary" condition is simple: you won't get reliable
software unless you take care to associate specifications --
contracts -- with software elements, especially reusable
components. You can then use these contracts to build
the software, to document it, to validate it statically,
to test it (if you have support for run-time monitoring,
as in Eiffel), to control the proper use of inheritance,
to discuss the software within the software team as well
as with management, customers, users and regulatory agencies.
Anyone who has used the approach knows that it dramatically
improves the quality of the product and the process.
And it's not even an expensive technique.>>


This is demonstrably false. There are lots of examples of highly reliable
software written by people who don't even know what a specification is,
let alone how to carefully associate them with software elements.

If you want details on this, I can send you hundreds of thousands of
lines of COBOL code. This code is completely inpenetrable in places,
and I consider it pretty horrible, but it is from a completely reliable
system, where reliability is measured in the terms that matter, i.e.
it does what it is supposed to do in a highly reliable manner.

The supportable statement is something like

"Associating specifications with software elements" is an important tool
that will aid in the production of reliable software.

Of course no one will disagree with that, what people might disagree with
is the huge leap to say

"Therefore any system that does not use DBC is not reliable"

But that is what the contrapositive of your first sentence above says.

As I said in my previous message, I don't think exaggerations of this
kind are helpful at all, even in a heated advocacy argument. They tend
to weaken a position, not strengthen it.

Robert

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Quoting my message that said among other things:
 
>>> The "necessary" condition is simple: you won't get reliable
>>> software unless you take care to associate specifications --
>>> contracts -- with software elements, especially reusable
>>> components. You can then use these contracts to build
>>> the software, to document it, to validate it statically,
>>> to test it (if you have support for run-time monitoring,
>>> as in Eiffel), to control the proper use of inheritance,
>>> to discuss the software within the software team as well
>>> as with management, customers, users and regulatory agencies.
>>> Anyone who has used the approach knows that it dramatically
>>> improves the quality of the product and the process.
>>> And it's not even an expensive technique.>>>,

Robert Dewar writes:

> This is demonstrably false. There are lots of examples of highly reliable
> software written by people who don't even know what a specification is,
> let alone how to carefully associate them with software elements.
> 
> If you want details on this, I can send you hundreds of thousands of
> lines of COBOL code. This code is completely inpenetrable in places,
> and I consider it pretty horrible, but it is from a completely reliable
> system, where reliability is measured in the terms that matter, i.e.
> it does what it is supposed to do in a highly reliable manner.

This is eloquently said, but incorrect all the same.

The definition of reliability which this implies is that a system
is "highly reliable" if it has been working satisfactorily for,
say, 30 {seconds | minutes | hours | days | weeks | months | years}
-- pick one. This is one possible definition of reliability, which gets
more and more interesting as it moves to the right of the list
of choices; but it is by no means the only "terms that matter".

True, it may be pragmatically sufficent in some cases.
For example if you tell me my car insurance is being computed
by a program that has worked "satisfactorily" for 10 years, I
may be reasonably pacified. After all, even though I know that
processing my case may hit a bug that no one encountered
before, the (damage * likelihood) factor is small enough for
me to accept the risk (although, being a computing scientist,
I might ask for evidence of what exactly you mean by
"satisfactorily" or even, using Prof. Dewar's terms,
"highly reliably").

But for a mission-critical system of the kind that started
this discussion -- one, such as Ariane, whose non-high-reliability
may imply loss of life, or destruction of huge amounts of
property, or some other catastrophic event -- that is not
good enough. "The software has passed the acceptance tests" or
even "the software has worked properly in the first two missions"
is interesting, but not sufficient to allay the concerns
of, e.g., regulatory agencies. I have seen requirement
specifications for mission-critical systems which
include formal conditions such as "at most one failure for each
10^n passengers", where n is a very large number  --
corresponding, say, to 500-year continuous operation.
Leaving aside the question of whether we can honestly make such
promises (since the scientific debate should not prevent us
to try our best as engineers), we are NOT going to reassure,
let alone satisfy our censors through pragmatic reliability
arguments of the form "it has worked well so far, ergo it is
reliable".  They will listen with interest but they will demand
more.
 

Part of what they will demand will be guarantee about our software
process -- something in the line of ISO 900x, Capability Maturity
Model, quality assurance plan and the like. But they will also
want to know what software techniques we use and, in particular,
why we believe that each software component does its
job -- especially a reusable software component pulled out
from somewhere else. This is where there is simply no substitute
for Design by Contract: a necessary condition, as I wrote.
By no means sufficient (it makes sense as part of an array
of reliability mechanisms, some technical, some organizational);
but, until someone comes with a better idea to guarantee
reliability, necessary.

The recently deceased Harlan Mills, then of IBM, published
in 1975 (Proc.Intl. Conf. on Software Reliability,
see reference in OOSC-2) a paper entitled

	"How to write correct programs, and know it."

This title truly capture the essence of the problem. It is
not sufficient, as Prof. Dewar seems to imply, to write
reliable programs (where reliability includes correctness)
which we think are reliable because they have worked well
enough for long enough. To convince others (and ourselves)
that they are indeed reliable, we need better arguments.
These arguments can only come from a precise description
of what the elements are supposed to do -- the contracts --
and some evidence that the implementation does honor the
contracts. Without these mechanisms in place, we cannot
even discuss properly the reliability of our software,
since we haven't even defined what we are talking about.

So when Robert Dewar writes

> "Associating specifications with software elements" is an important tool
> that will aid in the production of reliable software.

> Of course no one will disagree with that, what people might disagree with
> is the huge leap to say

> "Therefore any system that does not use DBC is not reliable"

I believe he is wrong on the second point, at least if we
replace "reliable", in the last line, by "demonstrably
reliable" (using "demonstrably" not in the absolute
mathematical sense but in the practical sense of being able
to convince competent colleagues).

My view here is, apparently at least, the exact reverse of
his. There is no claim whatsoever that Design by Contract
is "sufficient".  I would be happy to know a magical recipe
to guarantee software reliability, but I don't. I do know,
however, techniques that tremendously improve reliability
(techniques that have saved me and many other people
countless bugs, including some potentially spectacular
ones), and without which it is not possible, in the
state of software technology as I understand it, to achieve
similar results. In short, necessary conditions.

I understand that not everyone is convinced, and that some may
think the claims are too grandiose even though they are really
very modest and down-to-earth; but that does not diminish the
relevance of these techniques to software reliability, the
importance for every software engineer of learning them,
and, yes, their necessity.
 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Robert Dewar writes:
> 
> > This is demonstrably false. There are lots of examples of highly reliable
> > software written by people who don't even know what a specification is,
> > let alone how to carefully associate them with software elements.
> >
> > If you want details on this, I can send you hundreds of thousands of
> > lines of COBOL code. This code is completely inpenetrable in places,
> > and I consider it pretty horrible, but it is from a completely reliable
> > system, where reliability is measured in the terms that matter, i.e.
> > it does what it is supposed to do in a highly reliable manner.
> 
> This is eloquently said, but incorrect all the same.
> 
> The definition of reliability which this implies is that a system
> is "highly reliable" if it has been working satisfactorily for,
> say, 30 {seconds | minutes | hours | days | weeks | months | years}
> -- pick one. This is one possible definition of reliability, which gets
> more and more interesting as it moves to the right of the list
> of choices; but it is by no means the only "terms that matter".
> 
> True, it may be pragmatically sufficent in some cases.
> For example if you tell me my car insurance is being computed
> by a program that has worked "satisfactorily" for 10 years, I
> may be reasonably pacified. After all, even though I know that
> processing my case may hit a bug that no one encountered
> before, the (damage * likelihood) factor is small enough for
> me to accept the risk (although, being a computing scientist,
> I might ask for evidence of what exactly you mean by
> "satisfactorily" or even, using Prof. Dewar's terms,
> "highly reliably").
> 
> But for a mission-critical system of the kind that started
> this discussion -- one, such as Ariane, whose non-high-reliability
> may imply loss of life, or destruction of huge amounts of
> property, or some other catastrophic event -- that is not
> good enough. "The software has passed the acceptance tests" or
> even "the software has worked properly in the first two missions"
> is interesting, but not sufficient to allay the concerns
> of, e.g., regulatory agencies. I have seen requirement
> specifications for mission-critical systems which
> include formal conditions such as "at most one failure for each
> 10^n passengers", where n is a very large number  --
> corresponding, say, to 500-year continuous operation.
> Leaving aside the question of whether we can honestly make such
> promises (since the scientific debate should not prevent us
> to try our best as engineers), we are NOT going to reassure,
> let alone satisfy our censors through pragmatic reliability
> arguments of the form "it has worked well so far, ergo it is
> reliable".  They will listen with interest but they will demand
> more.
> 
> Part of what they will demand will be guarantee about our software
> process -- something in the line of ISO 900x, Capability Maturity
> Model, quality assurance plan and the like. But they will also
> want to know what software techniques we use and, in particular,
> why we believe that each software component does its
> job -- especially a reusable software component pulled out
> from somewhere else. This is where there is simply no substitute
> for Design by Contract: a necessary condition, as I wrote.

I have _safety-critical_ software systems in operation today that
were developed with a process that has been independently evaluated
to both ISO 9001 and SEI III. The products have been validated using
MIL-STD-882B and DoD-STD-2167, and also meet all validation requirements
for RTCA/DO-178B (although no customer has asked for this yet). No
agency responsible for acceptance of my products has ever raised the
issue of Design by Contract in the _specific_ sense used in the Ariane
paper.

I am also familiar with systems accepted under MoD DEF STANs (C-130, in
particular), and they did not require Design by Contract (although
SPARK was used on that system).

Can you identify a regulatory software safety standard that specifically
calls out Design by Contract? If so, please provide the citation; I
would be interested in reviewing it.

> By no means sufficient (it makes sense as part of an array
> of reliability mechanisms, some technical, some organizational);
> but, until someone comes with a better idea to guarantee
> reliability, necessary.

There are quantitative software reliability models; none, to my
knowledge, call out Design by Contract as specifically described
in your Ariane paper.

> The recently deceased Harlan Mills, then of IBM, published
> in 1975 (Proc.Intl. Conf. on Software Reliability,
> see reference in OOSC-2) a paper entitled
> 
>         "How to write correct programs, and know it."
> 
> This title truly capture the essence of the problem. It is
> not sufficient, as Prof. Dewar seems to imply, to write
> reliable programs (where reliability includes correctness)
> which we think are reliable because they have worked well
> enough for long enough. To convince others (and ourselves)
> that they are indeed reliable, we need better arguments.
> These arguments can only come from a precise description
> of what the elements are supposed to do -- the contracts --
> and some evidence that the implementation does honor the
> contracts. Without these mechanisms in place, we cannot
> even discuss properly the reliability of our software,
> since we haven't even defined what we are talking about.

See the work of Levison or Musa to alternative ways to
make these "arguments."

> 
> So when Robert Dewar writes
> 
> > "Associating specifications with software elements" is an important tool
> > that will aid in the production of reliable software.
> 
> > Of course no one will disagree with that, what people might disagree with
> > is the huge leap to say
> 
> > "Therefore any system that does not use DBC is not reliable"
> 
> I believe he is wrong on the second point, at least if we
> replace "reliable", in the last line, by "demonstrably
> reliable" (using "demonstrably" not in the absolute
> mathematical sense but in the practical sense of being able
> to convince competent colleagues).

I can provide specific factual evidence to the contrary.
Competent colleagues can be convinced through alternative means.

> 
> My view here is, apparently at least, the exact reverse of
> his. There is no claim whatsoever that Design by Contract
> is "sufficient".  I would be happy to know a magical recipe
> to guarantee software reliability, but I don't. I do know,
> however, techniques that tremendously improve reliability
> (techniques that have saved me and many other people
> countless bugs, including some potentially spectacular
> ones), and without which it is not possible, in the
> state of software technology as I understand it, to achieve
> similar results. In short, necessary conditions.
> 
> I understand that not everyone is convinced, and that some may
> think the claims are too grandiose even though they are really
> very modest and down-to-earth; but that does not diminish the
> relevance of these techniques to software reliability, the
> importance for every software engineer of learning them,
> and, yes, their necessity.

Can this necessity be correlated to a safety-critical system
in production? In what regulatory context was DBC used to
certify the system?

> 
> --
> Bertrand Meyer, President, ISE Inc.
> ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> http://www.eiffel.com, with instructions for free download
> == ISE Eiffel 4: Eiffel from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Bertrand Meyer wrote:
>
> Robert Dewar writes:
>
> > This is demonstrably false. There are lots of examples of highly reliable
> > software written by people who don't even know what a specification is,
> > let alone how to carefully associate them with software elements.
> >
> > If you want details on this, I can send you hundreds of thousands of
> > lines of COBOL code. This code is completely inpenetrable in places,
> > and I consider it pretty horrible, but it is from a completely reliable
> > system, where reliability is measured in the terms that matter, i.e.
> > it does what it is supposed to do in a highly reliable manner.
>
> This is eloquently said, but incorrect all the same.
>
> The definition of reliability which this implies is that a system
> is "highly reliable" if it has been working satisfactorily for,
> say, 30 {seconds | minutes | hours | days | weeks | months | years}
> -- pick one. This is one possible definition of reliability, which gets
> more and more interesting as it moves to the right of the list
> of choices; but it is by no means the only "terms that matter".
>


This is complete nonsense. I am talking about systems which are reliabale
by any conceivable measure.

Now of course if your measure of reliability includes that it must explicitly
use DBC, then you reduce your argument to a meaningless tautology.

Personally I find obviously bloated claims like this (my method is the
only one that can generate reliable code, and it is impossible to 
generate reliable code any other way) to be highly counter-productive.

I have occasionally heard people make similar bogus absolute claims for
Ada -- and in my opinion nothing is more damaging, since it causes people
who know better to simply ignore not only the obviously incorrect claim,
but also more reasonable claims.

In this particular case, the very reasonable point that DBC may be a useful
tool in helping to achieve reliability in some circumstances is getting
submerged by the more absurd claim that it is the only way to achieve this
goal.

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Note: Invectives ("complete nonsense", "bogus", "absurd" etc.)
serve no useful purpose. In particular they are not a
substitute for arguments. We are all very passionate
about these things, which is good, but I think we should
all continue to accept that the other side is not
completely incompetent. I certainly respect Robert
Dewar's views, even those (not all) with which I
disagree. (End of note.)

Robert Dewar initially wrote

> > reliability is measured in the terms that matter, i.e.
> > it does what it is supposed to do in a highly reliable manner.

which says little more than: a system is reliable if it is
highly reliable. It would be hard to quarrel with his statement,
but as a definition it's not very useful. He then refined
this definition into

> I said that the
> only measure of reliability that made any sense was that a program
> behaved in a realiable manner and did what it was supposed to do

Again, probably true but not sufficient as a definition. The
first part is a tautology (a program is reliable if it behaves
in a [reliable] manner -- sure). The second part, "[does] what is
supposed to do", is broadly correct as a general, informal
definition (although even so one can do better, in particular
by distinguishing between two components of reliability,
correctness and robustness), but is not enforceable in any way.
How do you know that a system "does what it is supposed to do"?
The most you can expect (in the absence of formal techniques) is,
as I wrote in my earlier message, that the program has "done
what it is supposed to do" for a certain period of time,
be it 30 seconds or 30 years.

        (And even that is subject to doubt,
        as you can hardly be sure that everything was perfectly
        all right. For example if we take one of the pragmatically
        reliable COBOL programs that Prof. Dewar cites, assuming
        it has been computing payroll taxes for the past 10 years,
        few people would bet $50,000 of their own money that no one
        will sue and win damages on the basis of wrongful operation
        of the program during that past period.) 

These are difficult issues and no one has a silver bullet. But
it turns out that it is possible to do better at least
at the component level. As Prof. Dewar has correctly pointed
out, specifying the behavior of a complete system -- i.e.
"what it is supposed to do" -- is hard. But for a component
of that system it is often possible to write such a specification,
partially or totally formal. This is what Design by Contract is
about.

The claim that it is necessary has an obvious basis: you can't
get the system right if you can't get the components
right. To get the components rights, you need to convince enough
people, beginning with yourself, that they are
"doing what they are supposed to do", and you can't do
that without stating what they are supposed to do,
as precisely as possible. The good news is that for a
component you can realistically be more precise than for
a whole system.

The more fundamental issue is that we need better ways
to achieve the reliability of mission-critical systems.
Not just better organization and management, but better
techniques. Design by Contract is one such technique. It
is not by itself the answer, but I think it is a required part
of the answer.


-- 
Bertrand Meyer

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Bertrand Meyer wrote:

> When the discussion turned to ... distortions of our views
> (e.g. that we had claimed that "DBC Eiffel is
> THE ONE method that could have found the Ariane 5 flaw"),

I'm glad to hear that this is a distortion of your views.

Unfortunately, your Ariane 5 column distorts your views the same
way.  The applicable quotes have been repeatedly posted.  If you
have responded to them before now, I've missed it.  This is the
first time I've seen you specifically disclaim the notion that
the Ariane 5 crash demonstrated the failure of current methods
(which were, in fact, unused on the Ariane 5 INS).

I'll be happy to re-post the quotes if you wish to explain how I
am mis-interpreting them.  I sincerely don't see how your paper
can support any other meaning.

Sam Mize

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Kenneth Almquist wrote (only last part of message quoted):
> 
> > This thread was started when Ken Garlington wrote a response to your
> > article about the Ariane V.  So far you have been unable or unwilling
> > to respond to the arguments contained in Ken Garlington's response.
> 
> That is incorrect. Jean-Marc Jezequel and I, plus many others
> familiar with the ideas of Design by Contract, have responsed
> repeatedly and in detail. Consult DejaNews for the record.

Could you provide a specific item? I reviewed DejaNews for my response.

I think it is fair to say that Jezequel and others have responsed in
detail
to the arguments in my response.

> When the discussion turned to ad hominem arguments (that I
> have a "vested interest", that our article was "advertising
> puffery" and "position[ed] deceptively as a technical item
> instead of an ad") and distortions of our views
> (e.g. that we had claimed that "DBC Eiffel is
> THE ONE method that could have found the Ariane 5 flaw"),
>
> I stopped, as there is no point in continuing in that mood.
> 
> The arguments and counter-arguments are widely available
> from the newsgroups and Web pages.
> 
> --
> Bertrand Meyer, President, ISE Inc.
> ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> http://www.eiffel.com, with instructions for download

Not that Mr. Meyer has a vested interest in Eiffel, of
course :)

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Bertrand said

<<> The definition of reliability which this implies is that a system
> is "highly reliable" if it has been working satisfactorily for,
> say, 30 {seconds | minutes | hours | days | weeks | months | years}
> -- pick one. This is one possible definition of reliability, which gets
> more and more interesting as it moves to the right of the list
> of choices; but it is by no means the only "terms that matter".>>


Incidentally I said nothing of the kind in my message, I said that the
only measure of reliability that made any sense was that a program
behaved in a realiable manner and did what it was supposed to do.

The idea that this implies that I think the only possible test of this
is to run the system and see if it works is an idea created by the
reader not the writer!

There are many ways that one can use to determine if a program is reliable.
For example, in some limited small cases, total proof of correctness may
be a useful tool. Certainly the contstruction of such proofs can be aided
by accurate assertions about the code, but such proofs do not (and cannot)
depend critically on the presence of such assertions.

Similarly, systematic coverage and branch testing are pretty much 
independent of whether DBC was or was not used.

Showing that a program is realiable is a complex process that involves
the use of many tools and techniques. Yes, in some cases, DBC may aid
this process, but the suggestion that no program can be realiable which
does not use DBC is plain unreasonable.

Re: Critique of Ariane 5 paper (finally!)

[Thomas Beale]

Robert Dewar wrote:
> 
> There are many ways that one can use to determine if a program is reliable.
> For example, in some limited small cases, total proof of correctness may
> be a useful tool. Certainly the contstruction of such proofs can be aided
> by accurate assertions about the code, but such proofs do not (and cannot)
> depend critically on the presence of such assertions.

As an observer to this long-winded thread, can I suggest that you define
what
you mean by reliable? Software engineers such as myself often use the
term 
"correctness" to mean what you seem to be talking about above. I would 
define "reliability" as the ability of a system to execute correctly
over 
some time, and with "normal" inputs ("robustness" would be a measure of
a 
system handling pathological inputs). Reliability in my experience has 
often been specified by an mtbf - mean time between failures - figure.
So 
the aspect of quality we are interested in here is longevity of correct 
operation, not just correct function. So, when you say "reliability",
exactly
what do you mean?

- thomas beale

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Thomas said

<<As an observer to this long-winded thread, can I suggest that you define
what
you mean by reliable? Software engineers such as myself often use the
term
"correctness" to mean what you seem to be talking about above. I would
define "reliability" as the ability of a system to execute correctly
over
some time, and with "normal" inputs ("robustness" would be a measure of
a
system handling pathological inputs). Reliability in my experience has
often been specified by an mtbf - mean time between failures - figure.
So
the aspect of quality we are interested in here is longevity of correct
operation, not just correct function. So, when you say "reliability",
exactly
what do you mean?>>


Sure I think we all accept your definition of reliability (the ability of
a system to execute  correctly ....) although we might want to add something
about ease of modification and maintenance (for me these are also aspects
of reliability).

But that definition is not one we can use directly to ensure reliability.
Sure we can judge in retrospect whether we succeeded in generating a
realiable application, but we can't use this criterion directly to ensure
reliability in advance.

If you look at my earlier postings, you will see that the point you are
making is *precisely* the one that I emaphasized in my replies to Bertrand.

Now what Bertrand claims is that any methodology which results in reliable
programs MUST ALWAYS use an approach that includes an explicit use of DBC.
What I am saying is that there are many methods and techniques that we
use in practice for judging reliability.

Correctness is a different property from reliability as you point out (there
are unreliable correct programs, and reliable incorrect programs). However,
that does not mean that demonstration of correctness is not a useful tool
in the quest after reliability. The effort to demonstrate correctness may
well show up flaws that would indeed effect reliability. Of course even if
you prove total correctness, you have not demonstrated reliability, but then
that is true of other techniques (such as formal testing, etc). In practide,
we ensure reliability by using a variety of techniques and tools.

DBC in the sense in which Bertrand means it is a possible tool. It is
neither necessary nor sufficient, but it is one more useful tool (I cannot
imagine anyone contesting this point). However, use of DBC does not ensure
reliability, and failure to use it does not guarantee unreliability!

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

<<I think one of the primary differences between correctness and
reliability is
that the former can be defined crisply while the latter cannot.>>


No, I disagree, these are completely different qualities, they are related,
but as I said earlier, you can have reliable programs that are not correct, and correct
programs that are not realiable.

Re: Critique of Ariane 5 paper (finally!)

[Jon S Anthony]

In article <3401811D.1700E7BE@stratasys.com> Jeff Kotula <jkotula@stratasys.com> writes:

> Robert Dewar wrote:
> 
> > No, I disagree, these are completely different qualities, they are
> > related,
> > but as I said earlier, you can have reliable programs that are not
> > correct, and correct
> > programs that are not realiable.
> 
> This is a nonsensical statement. In the first case, you will have a
> program
> that reliably does the *wrong* thing, and in the second case, you
> will have a program that doesn't do the right thing all the time.
> Neither of these cases is of any interest to the goal of creating
> high quality functioning software.

Wow.  This is amazingly naive.  You don't actually believe that in
anything but trivial cases you can prove correctness, do you?????

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Jeff Kotula wrote:
> 
> Robert Dewar wrote:
> 
> > <<I think one of the primary differences between correctness and
> > reliability is
> > that the former can be defined crisply while the latter cannot.>>
> >
> > No, I disagree, these are completely different qualities, they are
> > related,
> > but as I said earlier, you can have reliable programs that are not
> > correct, and correct
> > programs that are not realiable.
> 
> This is a nonsensical statement. In the first case, you will have a
> program
> that reliably does the *wrong* thing,

Exactly. Note that you used the word "reliable" to describe a reliable
program. Thus, it must be reliable!

> and in the second case, you
> will have a program that doesn't do the right thing all the time.

However, "correct" is not the same as "does the right thing".
Presumably,
"corrects" means "conforms to some testable definition of requirements."
A "correct" program may not be reliable, however, if used in some
context not anticipated by the requirements, for example.

> Neither of these cases is of any interest to the goal of creating
> high quality functioning software.

Actually, _both_ are of interest in terms of quality, as are "safe"
(which is something different from either reliability or correctness),
"portable," "maintainable," etc.

More to the point, it is critically important not to confuse these
attributes, since they (as Dr. Dewar has noted) are not synonyms.

Re: Critique of Ariane 5 paper (finally!)

[Jeff Kotula]

Ken Garlington wrote:

> Jeff Kotula wrote:
> >
> > Robert Dewar wrote:
> >
> > > <<I think one of the primary differences between correctness and
> > > reliability is
> > > that the former can be defined crisply while the latter cannot.>>
> > >
> > > No, I disagree, these are completely different qualities, they are
>
> > > related,
> > > but as I said earlier, you can have reliable programs that are not
>
> > > correct, and correct
> > > programs that are not realiable.
> [snip]
> More to the point, it is critically important not to confuse these
> attributes, since they (as Dr. Dewar has noted) are not synonyms.

I never said they were the same thing (see my orginal post included
in above. I only said that one could be quantified more easily
than the other.

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Jeff Kotula wrote:
> 
> Ken Garlington wrote:
> 
> > Jeff Kotula wrote:
> > >
> > > Robert Dewar wrote:
> > >
> > > > <<I think one of the primary differences between correctness and
> > > > reliability is
> > > > that the former can be defined crisply while the latter cannot.>>
> > > >
> > > > No, I disagree, these are completely different qualities, they are
> >
> > > > related,
> > > > but as I said earlier, you can have reliable programs that are not
> >
> > > > correct, and correct
> > > > programs that are not realiable.
> > [snip]
> > More to the point, it is critically important not to confuse these
> > attributes, since they (as Dr. Dewar has noted) are not synonyms.
> 
> I never said they were the same thing (see my orginal post included
> in above. I only said that one could be quantified more easily
> than the other.

Which is also not true. Quantitative software reliability models have
been around for many years.

In fact, "correctness" (depending upon your definition) can be much
harder to _quantify_ (assign a number) than "reliability"!

Re: Critique of Ariane 5 paper (finally!)

[Nick Leaton]

Thomas Beale wrote:

> Where I think there is more room for debate is in how DBC should be
> implemented. I have used Eiffel's DBC for some time, and it is miles
> ahead of no DBC. On the other hand, I am sure that there is empirical
> and theoretical work to be done which will show how the current idea
> in Eiffel can be improved, for example, how to determine the
> minimum set of orthogonal assertions for a precondition or invariant,
> and whether "synonymous" assertions are good or not. Quantitative
> statements have also been mentioned as a desirable thing. I believe
> gap between requirements specification and implementation is narrowing:
> better formal expression of at least some requirements may soon have
> a 1:1 counterpart in an implementation formalism, paving the way for
> very seamless software.

Explain a bit more about what you mean by 'synonymous'?

-- 

Nick

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Thomas Beale wrote:
> 
> Ken Garlington wrote:
> >
> I've been caught out using a very informal argument and relying
> on "commonly agreed" norms of software engineering. But as you
> imply, (and I have done often enough, many of these can be
> wrong). So...
> 
> > > Jeff Kotula wrote:
> > > > 1. Any evaluation of a system's reliability must be based on its
> > > > requirements specification.
> >
> > False. The Musa model, for example, does not require examination
> > of a requirements specification.
> 
> I don't know what the Musa model is; does its definition of reliability
> of a system rely in no way on the requirements (or any transformation of
> any expression of it)? If not, does its idea of reliability not relate
> to any expression of the correctness of the system (of which the
> requirements spec is an instance)?

In a grossly oversimplified sense, it requires a set of tests performed
according to certain groundrules, the collection of faults detected over
time from those tests, and the application of a model to determine the
residual faults. I suppose you could claim that the tests would be
based on the requirements specification, although they could just as
easily be generated by the end user without reference to that
specification.
It certainly relates to an expression of the "correctness" of the
system,
but I never claimed otherwise.

The key of Musa (and several other models) is to execute the system over
time based on it's predicted operational profile (how it is expected to
be used). This is not necessarily the same as what's in the requirements
spec, which may be written more in terms how it _could_ be used.

There's a large amount of information available on quantitative
software reliability; I've been planning to get Lyu's "Handbook
of Quantitative Software Reliability," which I've heard is good.

> > > > 2. Any evaluation of a system's reliability will directly correlate with
> > > > the reliability of its component's reliability.
> >
> > For software, not true. See "Safeware." The sum of the component
> > reliability
> > does not necessarily equal the system's reliability. (This is a common
> > mistake made when attempting to apply hardware reliability models to
> > software.)
> 
> I would have to agree here. A better statement would have been:
> "A system's unreliability will strongly correlate to the unreliability
> of the components". I.e., you can build rubbish out of good bits, but
> its unlikely (if not impossible) to build a good system out of
> broken components.

There's _some_ correlation; it depends upon the system design, etc. as
to
the strength of the correlation for a given component. In the
extreme case, a completely broken component that's never executed
will not degrade system reliability.

More to the point, individual components that, individually, have high
reliability may exhibit low reliability when used together.

> > > > 3. Any evalution of a component's reliability must be based on its
> > > > requirements specification.
> >
> > Again, not true. See above.
> 
> I would need to be convinced by this "Musa" argument...
> 
> > > which closes the loop from requirements to implementation. I think
> > > this argument is a pretty fair statement of why DBC is not just another
> > > tool in the toolkit: (to paraphrase the above) DBC is a way of
> > > formalising, implementing, and enforcing the requirements specification
> > > at the design and implementation levels of abstraction.
> >
> > Unfortunately, there can be elements of the requirements specification
> > which cannot be enforced at the implementation level (e.g. certain
> > classes of assumptions about the external environment).
> 
> Naturally... probably the majority (measured by pages of document or
> whatever) is informal or semi-formal, and does not map directly to
> the various levels of design/implementation. But on the other hand,
> if contracts were used as a formalism in the reqts spec, then the
> ability to map through would be better.

Or (and IMHO, this is the more likely outcome) the informal requirements
are merely pushed up a level, into a system document for example. There
can certainly be exceptions; a spec for math routines can be formalized,
for example, but a general-purpose system involving a human in the
specification will likely, at some point, require a natural language
description of the expectations.

> > > Where I think there is more room for debate is in how DBC should be
> > > implemented. I have used Eiffel's DBC for some time, and it is miles
> > > ahead of no DBC.
> >
> > What did you use before DBC?
> 
> At university (Qld, Australia), we used formal assertions (a la
> Dijkstra) to specify the meaning of program components. There
> were no tools to support this, but we could easily code up test
> cases to test correctness by encoding these statements (in
> "pascal plus").
> 
> I spent about 6 years in distributed real-time SCADA systems
> coded in K&R C, and at the end, had come to the conclusion (along
> with other team members and developers) that modules built using
> PRE_CONDITION, POST_CONDITION, and CHECK (macro) statements
> in the code were better because:
> 
> a) they were more readable & thus maintainable;
> 
> b) they produced much more useful man pages (we built automated
>    back-extraction tools) - developers could avoid defensive
>    programming & complain to the authors if their program
>    died in a way forbidden by the assertion statements;
> 
> c) they were _much_ easier to debug (we used the Fred Fish dbug
>    macros as well, and integrated them with the assertions);
> 
> d) they acted as a repository for design-level decisions, which
>    began to replace voluminous design documentation which was
>    immediately out of date;
> 
> e) the incentive was there to write more generic, re-usable
>    modules, since for the first time, client developers had
>    a trustworthy way of knowing what a given module did,
>    without having to look at the code: the (automatically
>    extracted) man page with both function signatures (like
>    you get if you do "man strcat" for example, on a unix
>    system), and the pre- and post-condition statements....
>    this was treated as the "truth". A new experience -
>    trust in software not written by me - was discovered.
> 
> Although we never had the means or time to make comparative
> studies of code done this way versus the old way, I  believe
> we were able to write much better software, more quickly, and
> that it was more reliable because a) our ability to test it
> was much better, and b) it tended to get re-used more often
> (and hence further tested).
> 
> I should mention that we weren't doing this for amusement
> either: these systems control e.g. gas pipelines, electric
> power transmission and distribution systems (e.g. Sydney...),
> and passenger rail systems. Reliability was the most
> important thing in the world.
> 
> As well as the eariler Dijkstra/Hoare etc work, Meyer's
> original OOSC was a major influence on this work, since it
> encouraged us to think it would be possible to do this
> kind of thing in actual software (not hidden away in
> some document), and it showed us what reasonable syntax
> might look like for object-oriented software.
> 
> Since then I have felt that formalisms that don't support
> these ideas are way behind those that do. Eiffel is the
> only out-of-the-box formalism in this category that is
> available for building object-oriented software, but other
> formalisms (even the augmented C "formalism" I describe
> above) have great merit. It just depends on how much pain
> you want to go through to make reliable software.
> 
> I have since used Eiffel for some years because
> - I am allergic to pain,
> - it does the rest of the OO paradigm so well.
> 
> - thomas beale

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Robert Dewar wrote:
> 
> DBC in the sense in which Bertrand means it is a possible tool. It is
> neither necessary nor sufficient, but it is one more useful tool (I cannot
> imagine anyone contesting this point). However, use of DBC does not ensure
> reliability, and failure to use it does not guarantee unreliability!

I think we can go further. With respect to the available techniques
(Musa
et. al.) to _quantify_ software reliability, none of the models to my
knowledge require DBC. You can argue that DBC would _improve_ the
quantified values (or argue that none of the models are useful), but
there is no evidence that DBC is _required_ to have a given level
of reliability, as measured by these models. Furthermore, of the
widely-used certification techniques that attempt to _qualitatively_
establish reliablilty, either of the product directly (882C, 178B,
etc.), the only one I can think of that even potentially could be
read as "requiring" DBC is 00-55/00-56, and I know of at least
one system qualified under that standard that did not use executable
assertions. Thus, I would assume that Mr. Meyer's relucance to
cite a specific case where DBC was required to satisfy a customer
as to the reliability of a system is... because he doesn't know of
a system that requires it!

Note that reliability (like safety) is not an absolute measure.
Systems are not "reliable" or "safe," they are merely more or
less reliable/safe than other alternatives. This is a big point
of "Safeware," which I would recommend highly to anyone participating
in a discussion of safety or reliability.

Re: Critique of Ariane 5 paper (finally!)

[W. Wesley Groleau x4923]

> The supportable statement is something like
> "Associating specifications with software elements" is an important 
> tool that will aid in the production of reliable software.

what some people disagree with is the use of two definitions of
DBC by the same advocates.

Def'n 1 - Associating specifications with software elements" and 
related practices.
Def'n 2 - The Eiffel implementation of a subset of these practices.

Now before anyone denies having used definition 2,  please explain
what definition of DBC satisfies the claim "only Eiffel directly
supports DBC"

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

W. Wesley Groleau wrote:
 
> what some people disagree with is the use of two definitions of
> DBC by the same advocates.
> 
> Def'n 1 - Associating specifications with software elements" and
> related practices.
> Def'n 2 - The Eiffel implementation of a subset of these practices.
> 
> Now before anyone denies having used definition 2,  please explain
> what definition of DBC satisfies the claim "only Eiffel directly
> supports DBC"

This has been explained many times. One can to some degree
apply the principles of Design by Contract in any language,
but among commercially commercially available languages Eiffel
is the only one to offer direct support for "associating
specifications with software elements" as part of the software
elements themselves, i.e. using language constructs --
preconditions, postconditions, class invariants, loop invariants,
loop variants.

In other languages you have to resort to purely methodological
guidelines or to comment conventions etc.
It's better than nothing, but does not go as far, because
the presence of the assertion constructs provides Eiffel
users  with major benefits such as: 

	- Documentation tools (in the supporting environments)
	  that extract the specification from the software.
	  Such tools provide a standard form of documentation
	  for reusable components and are essential to the success
	  of reusability efforts.
	  
	- Better reusable libraries (this too is a property
	  of the environments, made possible by the language)
	  thanks to their extensive
	  use of assertions (e.g. EiffelBase). Also,
	  these libraries naturally serve as models and
	  guides for users learning the approach, so they
	  indirectly lead to  more reliable and clearer
	  application software. 

	- Runtime assertion monitoring (again in the
	  environments) providing a particularly effective
	  tool for testing, debugging and quality assurance.

	- Language rules that associate assertions with
	  inheritance: precondition weakening and postcondition
	  strengthening in routine redefinitions, invariant
	  accumulation (a class inherits its parents'
	  integrity constraints). This is essential to
	  control the power of polymorphism and dynamic
	  binding, further decreasing bug sources.

	- Close connection with the exception handling
	  mechanism.

	- Simplification of the software's structure, since
	  supplier classes can avoid redundant checking
	  of special cases in the presence of preconditions.

	- General improvements in software quality: having
	  a construct in the language itself encourages
	  developers to use it -- especially, as noted, thanks to
	  the influence of reusable components --,  more so than
	  a purely methodological injunction to "be good"
	  and specify. In other words, use of Eiffel
	  helps promote a quality-oriented and
	  reliability-conscious mindset. This is a less
	  directly palpable benefit (and please do not
	  construe it as a claim that "Eiffel users make
	  no errors", no one ever said that) but significant
	  all the same.

Most of this is unique to Eiffel among widely used commercial
languages. Again it does not mean that you cannot get any benefit
of Design by Contract in other languages; you can (especially
if you have used Eiffel before: many people have noted that
you can become a better C++ programmer, for example, if you have
been trained in Eiffel; see e.g the educators' testimonials at
http://www.eiffel.com/services/university/). But you will
get much more in Eiffel.


-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with download instructions

Re: Critique of Ariane 5 paper (finally!)

[W. Wesley Groleau x4923]

> > what some people disagree with is the use of two definitions of
> > DBC by the same advocates.
> >
> > Def'n 1 - Associating specifications with software elements" and
> > related practices.
> > Def'n 2 - The Eiffel implementation of a subset of these practices.
> >
> > Now before anyone denies having used definition 2,  please explain
> > what definition of DBC satisfies the claim "only Eiffel directly
> > supports DBC"
> 
> This has been explained many times. One can to some degree
> apply the principles of Design by Contract in any language,
> but among commercially commercially available languages Eiffel
> is the only one to offer direct support for "associating
> specifications with software elements" as part of the software
> elements themselves, i.e. using language constructs --
> preconditions, postconditions, class invariants, loop invariants,
> loop variants.

I say again: If DBC is defined as "Associating specifications 
with software elements", then Eiffel indeed directly supports 
a SUBSET of DBC.  Ada directly supports another subset of DBC.
C++ (shudder) directly supports yet another subset of DBC.  And 
with a little extra work, the user of any of these languages can 
handle a larger subset.  But none of them can completely support 
the whole thing.  And the intersection of the subsets is not empty.

I keep seeing most of the Eiffel advocates and a few of the Ada
advocates arguing, "My language supports DBC; your language does 
not look like my language; therefore your language does not 
support DBC."  Yet when they post specific examples, the syntax 
differences cannot hide (from me at least) the obvious similarities.

> In other languages ... does not go as far, because
> the presence of the assertion constructs provides Eiffel
> users with major benefits such as:

[ a long list of things that ARE being done with Ada and other
  languages ]

[ followed by the claim that only Eiffel users do these things. ]

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

Bertrand said

<<OK, finally things are clear. When everything else fails, resort
to questioning the other person's integrity: I have a vested
interest in seeing Eiffel succeed.>>

I think you missed my point. Everyone knows that you have a vested
interest in seeing Eiffel succeed. Everyone knows that I have a vested
interest in seeing Ada succeed. Nothing wrong with either situation,
and it does not damage our integrity that we have these vested interests.

What I was saying is that in this situation you have to be very careful
that claims you make are solidly based, and objectively supportable.
Personally I find people who make puffed claims for Ada a real menace,
and I don't think it helps Ada one bit.

In this case, I agree that DBC would have been sufficient, if employed
in certain ways, to avoid the Ariane problem, but then so would a zillion
other reasonable approaches.

Arguing the benefits of DBC with regard to Ariane is perfectly legitimate.
To say, or even vaguely imply, that it is a necessary part of any approach
that could have solved this problem is so obviously "advertising puffery"
[i.e. advocacy for a technology without any basis in fact] that it should
be dismissed as such.

If you never made a such a claim, then obviously what I say is
inapplicable, and the person quoting this claim was in error (I really
don't remember who it was that introduced this claim into the thread).

I really think that your position is stronger if you are very careful
to avoid over-inflated claims. That's because otherwise people will
dissmiss them on the basis of self-interest. That's not a matter of
questioning your integrity at all. It's a matter of effective tactics.

I try to avoid making *any* positive statements about Ada that I cannot
back up, precisely because I figure that people will just dismiss them
on the grounds that I am trying to get rich (if it were true, which it
is not, then I guess it just shows I don't succeed at everything I try :-)

Anyway, I certainly did not mean to offend here, and I apologize if I did.

Robert

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Robert Dewar wrote:
> 
> Bertrand says
> 
> <<As convincingly as I could, my colleagues and I
> have explained: why in our view
> software technology crucially requires the systematic use of
> Design by Contract; why Design by Contract is a
> necessary condition to avoid more Ariane-like failures;
> and what is missing in this respect in such approaches
> as Java, Ada, C++, IDL.>>
> 
> Your argument at *best* says that DBC might have been a *sufficient*
> condition for avoiding the Ariane failure. Even there, it seems
> over-facile and rather academic, and does not seem to understand
> fully the exact nature of the Ariane problem.

DBC proponents have said that using DBC IMPLIES review of
requirements, review of design, and testing the component.
In this case, the claim that DBC would "probably" have prevented
the crash is nugatory but true.

However, the claim that "widely accepted industry practices" would
not have done so is false.  Requirements review, design review, and
in-situ test are standard for a mission-critical component.  Not
ONE of these was done for the Ariane 5 INS.  To claim that this is
"widely accepted industry practice" is disingenuous at best, and
appears intentionally misleading to a lot of us.

It is this false claim that destroys the argument that DBC is
"a necessary condition to avoid more Ariane-like failures."

It's rather like saying that a new method of navigation would
"probably" have prevented the Exxon Valdez crash.  True, but
only because ANY navigation would have prevented it!


> But to make the jump from sufficient to necessary is completely
> without basis, and can only be regarded as advertising puffery.

Which appeared in a column in IEEE Computer magazine, positioning
it deceptively as a technical item instead of an ad.

Samuel Mize

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Samuel Mize wrote:
> 
> Robert Dewar wrote:
> >
> > Bertrand says
> >
> > <<As convincingly as I could, my colleagues and I
> > have explained: why in our view
> > software technology crucially requires the systematic use of
> > Design by Contract; why Design by Contract is a
> > necessary condition to avoid more Ariane-like failures;
> > and what is missing in this respect in such approaches
> > as Java, Ada, C++, IDL.>>
> >
> > Your argument at *best* says that DBC might have been a *sufficient*
> > condition for avoiding the Ariane failure. Even there, it seems
> > over-facile and rather academic, and does not seem to understand
> > fully the exact nature of the Ariane problem.
> 
> DBC proponents have said that using DBC IMPLIES review of
> requirements, review of design, and testing the component.
> In this case, the claim that DBC would "probably" have prevented
> the crash is nugatory but true.

Note that Mr. Jezequel, one of the authors of the DBC Ariane paper,
argued for some time that the tests described in the inquiry's
report were infeasible, and that DBC would substitute for them.
Therefore, it does not seem valid to assume that DBC equates to
full testing. 

See also my arguments in section 3.2 (and subsections) of
  http://www.flash.net/~kennieg/ariane.html

> However, the claim that "widely accepted industry practices" would
> not have done so is false.  Requirements review, design review, and
> in-situ test are standard for a mission-critical component.  Not
> ONE of these was done for the Ariane 5 INS.  To claim that this is
> "widely accepted industry practice" is disingenuous at best, and
> appears intentionally misleading to a lot of us.

I'm not sure that a requirements and/or design review was left out
of the process. I think it is more clear to say that insufficient
review by _external parties_ was performed; parties with sufficient
independence and knowledge to identify the invalid assumption.

> It is this false claim that destroys the argument that DBC is
> "a necessary condition to avoid more Ariane-like failures."
> 
> It's rather like saying that a new method of navigation would
> "probably" have prevented the Exxon Valdez crash.  True, but
> only because ANY navigation would have prevented it!
> 
> > But to make the jump from sufficient to necessary is completely
> > without basis, and can only be regarded as advertising puffery.
> 
> Which appeared in a column in IEEE Computer magazine, positioning
> it deceptively as a technical item instead of an ad.

I suppose for the sake of fairness, that it should be pointed out that
Mr. Meyer may not consciously be attempting promotion of his products
through this means. How would we know? I do get the feeling that
much of his defense of his paper is based on emotion rather than
logic. He has yet to engage in a discussion of the issues; most of
his responses have either been in terms of his "wounded pride," or
oblique personal attacks ("if only practitioners would listen to the
voice of reason"), or mere filler ("we'll just have to agree to
disagree," as in this latest post). Mr. Jezequel was at least willing
to discuss some issues (e.g. the potential for testing), and did
soften his stance in some areas as a result (as did I). However,
he soon gave up the discussion, which was unfortunate.

I also agree that it's unfortunate that IEEE Computer doesn't publish
more critical letters. In particular, it's difficult to explain a
contrary postion adequately in the space provided. It also is much
less likely to be read.

> 
> Samuel Mize

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Samuel Mize wrote:
 
> > But to make the jump from sufficient to necessary is completely
> > without basis, and can only be regarded as advertising puffery.
> 
> Which appeared in a column in IEEE Computer magazine, positioning
> it deceptively as a technical item instead of an ad.

This is outrageous. The article in question suggested a technical
principle (Design by Contract) to avoid new occurrences
of a documented major disaster. It did not mention any
software product. IEEE Computer and other magazines
publish thousand of pages suggesting technical solutions
to problems -- often, in fact, advocating products
and companies. Is any argument for CORBA, or OLE, or UML, or
Unix, or Windows to be dismissed as as "deceptive",
an "ad" and not a "technical item"?

For example the June issue of IEEE Computer included a 6-page
eulogy of Java by its creator, James Gosling. Is this a
deceptive ad too? After all, unlike the Ariane paper, it does
talk throughout about its author's company (Sun) and products
(Solaris etc.) But if we barred technical advocacy, IEEE
Computer and other magazines would soon become rather boring
places. Fortunately I don't think that's going to happen.

The underlying issue is what we do to improve software
reliability, and that's not going to be resolved by 
gratuitous attacks.
 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for free download

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Samuel Mize wrote:
> 
> > > But to make the jump from sufficient to necessary is completely
> > > without basis, and can only be regarded as advertising puffery.
> >
> > Which appeared in a column in IEEE Computer magazine, positioning
> > it deceptively as a technical item instead of an ad.
> 
> This is outrageous. The article in question suggested a technical
> principle (Design by Contract) to avoid new occurrences
> of a documented major disaster. It did not mention any
> software product.

Except Eiffel, of course. It went on to contrast Eiffel with other
competing product lines. The fact that you were identified as
"Bertrand Meyer, EiffelSoft" didn't help either. (Not your fault,
of course, but it adds to the perception).

Contrast this, for example, to your outstanding article on object
taxonomies. Although you used Eiffel for your examples, nowhere
did you say, "and Eiffel is much better than Java, Ada, etc. at
expressing these taxonomies."

You have to agree that someone who makes money selling books and
products for both DBC and Eiffel should be both conservative and
balanced in their claims, to avoid the _appearance_ (and I stress
appearance, because I'm not suggesting you intentionally meant to
advertise your products) of a conflict of interest.

> IEEE Computer and other magazines
> publish thousand of pages suggesting technical solutions
> to problems -- often, in fact, advocating products
> and companies. Is any argument for CORBA, or OLE, or UML, or
> Unix, or Windows to be dismissed as as "deceptive",
> an "ad" and not a "technical item"?
> 
> For example the June issue of IEEE Computer included a 6-page
> eulogy of Java by its creator, James Gosling. Is this a
> deceptive ad too? After all, unlike the Ariane paper, it does
> talk throughout about its author's company (Sun) and products
> (Solaris etc.) 

Given that you have described his argument as a "eulogy," then
I guess the answer is yes, you can dismiss (or at least question)
an argument where there is a perception of strong bias
(particularly financial gain). I know I question some of the
claims made by Java, as do you (see, for example):

            NEWS ITEM OF THE WEEK: 
   MICROSOFT DECLARES WAR ON JAVA PORTABILITY

at http://www.eiffel.com, "NEW" index item.

> But if we barred technical advocacy, IEEE
> Computer and other magazines would soon become rather boring
> places. Fortunately I don't think that's going to happen.
> 
> The underlying issue is what we do to improve software
> reliability, and that's not going to be resolved by
> gratuitous attacks.

Well said!

Having put the gratuitous attacks aside, I would appreciate
your review and comments on my paper at:

  http://www.flash.net/~kennieg/ariane.html

which, to the best of my ability, contains no gratuitous
attacks of any kind.

> 
> --
> Bertrand Meyer, President, ISE Inc.
> ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> http://www.eiffel.com, with instructions for free download

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Ken Garlington wrote:

> Bertrand Meyer wrote:

>>>> The [Jezequel-Meyer IEEE Computer] article did not mention
>>>> any software product.

> Except Eiffel, of course. It went on to contrast Eiffel with other
> competing product lines.

Absolutely wrong.  Eiffel is not a product.
It is a non-proprietary method and language for the
construction of quality software.

The article did not mention any products. It was about
principles of software design and how they can help avoid
Ariane-like catastrophes.
 
-- BM

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Ken Garlington wrote:
> 
> > Bertrand Meyer wrote:
> 
> >>>> The [Jezequel-Meyer IEEE Computer] article did not mention
> >>>> any software product.
> 
> > Except Eiffel, of course. It went on to contrast Eiffel with other
> > competing product lines.
> 
> Absolutely wrong.  Eiffel is not a product.
> It is a non-proprietary method and language for the
> construction of quality software.

We'll just have to agree to disagree on whether Eiffel is
_also_ a product line.

"Personal Eiffel for Windows: $69.95 (electronic version)."
          ------
from the page titled:

"Prices for ISE Eiffel products and support"
                ---------------------------
on the server

http://www.eiffel.com.
           ----------

> The article did not mention any products. It was about
> principles of software design and how they can help avoid
> Ariane-like catastrophes.

I believe you. However, as I tried to explain in very
precise terms, many people were left with the _impression_
that it was also a sales brochure. With a slightly different
approach, you could have still made your point wihtout making
such an impression.

I suppose you could say that impressions are irrelevant.
However, this is certainly an odd position to take for
someone advocating a method and language, not to mention
someone in the business world.

Overall, I'd have to say your responses to legitimate questions
are so emotional and acidic as to make it difficult for
some people to take you seriously. Given that these are the
same practitioners you're trying to convince...

> 
> -- BM

Re: Critique of Ariane 5 paper (finally!)

[Jon S Anthony]

In article <33F440F5.5A6@flash.net> Ken Garlington <kennieg@flash.net> writes:

[...speaking about some more BM "statements"...]

> Overall, I'd have to say your responses to legitimate questions are
> so emotional and acidic as to make it difficult for some people to
> take you seriously. Given that these are the same practitioners
> you're trying to convince...

IMO, Meyer should print this out, blow it up, and glue it to his
computer screen.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Jon S Anthony wrote:
> 
> In article <33F440F5.5A6@flash.net> Ken Garlington <kennieg@flash.net> writes:
> 
> [...speaking about some more BM "statements"...]
> 
> > Overall, I'd have to say your responses to legitimate questions are
> > so emotional and acidic as to make it difficult for some people to
> > take you seriously. Given that these are the same practitioners
> > you're trying to convince...
> 
> IMO, Meyer should print this out, blow it up, and glue it to his
> computer screen.

Unfortunately, I'm pretty sure my messages are marked in Mr. Meyer's
"kill" file (his mental one, if not his computer one :). However, if
someone _did_ want to have a technical discussion about the merits
of Eiffel as applied to the Ariane 5 case, my starting position is at

  http://www.flash.net/~kennieg/ariane.html

(I know it's a bore to see this repeated, but since it hasn't appeared
on any of the "official" Eiffel web sites to my knowledge, it's pretty
much the only way people can find it...)

------------------------------------------------------------

Subject: Rebuttal to Ariane paper
   Date: Mon, 04 Aug 1997 18:48:49 -0500
   From: Ken Garlington <kennieg@flash.net>
    To:  jezequel@irisa.fr
    CC:  Bertrand.Meyer@eiffel.com

In article <5qitoi$fdv$1@news.irisa.fr> on 1997/07/16, you wrote:

> Just for the record, I'm still waiting for your rebuttal paper
> to put it on my web alongside with the Computer article.

It's now available at:

  http://www.flash.net/~kennieg/ariane.html

Will the "master" version on www.eiffel.com also be changed to point to
this, or just a copy at www.irisa.fr?

Re: Critique of Ariane 5 paper (finally!)

[Jon S Anthony]

In article <33F22AD8.41C67EA6@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

> > Which appeared in a column in IEEE Computer magazine, positioning
> > it deceptively as a technical item instead of an ad.
> 
> This is outrageous. The article in question suggested a technical

Perhaps, but since this is a pretty wide spread impression, it may be
worth considering which side of the "desk" it originates.

> solution (Design by Contract) to avoid new occurrences
  ^^^^^^^^

Interesting that you changed this in your own followup to your own
post here.


> For example the June issue of IEEE Computer included a 6-page eulogy
> of Java by its creator, James Gosling. Is this a deceptive ad too?

Possibly.  Wouldn't surprise me in the least.

> technical advocacy, IEEE Computer and other magazines will soon
> become rather boring places. Fortunately I don't think that's going
> to happen.

Possibly - or more reasonable and cogent.

> It seems that the idea of using modern techniques to
> improve software reliability shocks some people so much

There is nothing new about assertions or the notion behind DBC.  The
basic ideas have been floated in various forms for a looonnggg time
now.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Critique of Ariane 5 paper (finally!)

[geldridg]

In article <JSA.97Aug14131421@alexandria.organon.com>,
jsa@alexandria.organon.com says...
>
>In article <33F22AD8.41C67EA6@eiffel.com> Bertrand Meyer
>><Bertrand.Meyer@eiffel.com> writes:

[...]

>> It seems that the idea of using modern techniques to
>> improve software reliability shocks some people so much
>
>There is nothing new about assertions or the notion behind DBC.  The
>basic ideas have been floated in various forms for a looonnggg time
>now.

.. and Bertrand Meyer will be the first to acknownledge such.

I think the following beta-release `Eiffel Liberty Journal' (elj)
article by Bertrand Meyer, titled:

 `Eiffel's Design by Contract: Predecessors and Original Contributions'

at:

 http://www.progsoc.uts.edu.au/~geldridg/eiffel/liberty/v1/n1/bm/bmdbc.html

might shed some more light on your comments.

Hope this helps.

Geoff Eldridge

-- geldridg@progsoc.uts.edu.au

Re: Critique of Ariane 5 paper (finally!)

[Matthew Heaney]

In article <JSA.97Aug14131421@alexandria.organon.com>,
jsa@alexandria.organon.com (Jon S Anthony) wrote:

>> It seems that the idea of using modern techniques to
>> improve software reliability shocks some people so much
>
>There is nothing new about assertions or the notion behind DBC.  The
>basic ideas have been floated in various forms for a looonnggg time
>now.

Perhaps that's true, but I myself didn't learn this until I read Bertrand's
book back in '89.   You can trace axiomatic specification back to the Floyd
article, the Hoare article (and to the "Little Black Book"), and the later
papers about ADTs by Guttag, Liskov, and Reynolds, but I don't think it's
inappropriate to give Bertrand credit for popularizing the idea of a
contract between client and server.

Had he not brought the contract model to the masses (it rode the wave of
popularity of the object movement), I'm not sure I or anyone else would be
arguing about it now.  I read his book with the intention of learning about
object-oriented programming, but came away with much more than that.  To
me, the concept of design by contract is at least as important as object
technology.  (Indeed, as our discipline matures, we see that there are
myriad "architectural styles," object-oriented being only one of them.  But
the contract idea will always be applicable, no matter how you build your
house.)

Bertrand and I have plenty to disagree about (Ada is AOK with me, thank you
very much), but the efficacy of design by contract is not one of them.  He
would be wise to not claim too much credit, to avoid the mistakes of his
peers (What exactly is the "Booch method"?  Or the "Object Modeling
Technique"?  Are Grady's objects any different from mine or yours?), but
the effect of Bertrand's cogent enunciation of the contract philosophy is
undeniable.

I can say without hyperbole that Object-Oriented Software Construction
changed my whole way of thinking about programming, and I consider that
book to be among the finest software engineering texts ever written.

So sally forth, Bertrand, and thank you!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Jon S Anthony wrote:
 
> There is nothing new about assertions or the notion behind
> [Design by Contract].  The basic ideas have been floated in
> various forms for a looonnggg time now.

If this is what the discussion finally amounts to, it is hard
to resist self-quoting from the second paragraph of the
preface to "Object-Oriented Software Construction"
(http://www.eiffel.com/doc/manuals/technology/oosc/preface):

 	just as inevitable is the well-known three-step sequence
	of reactions that meets the introduction of a new
	methodological principle: (1) "it's trivial"; (2) "it
	cannot work"; (3) "that's how I did it all along anyway".
	(The order may vary.)

I guess we have reached the third step now.

More seriously, it is absolutely correct that Design by
Contract is based on ideas that have been around for a long
time. It is also true that it includes original ideas too,
including some which in my experience shock most people
who encounter them for the first time, such as the
idea that to obtain more reliable software you should
usually *remove* checks. See also the connection with
inheritance (weakening/strengthening), the connection
with exceptions etc.

The question originality came up not long ago on comp.lang.eiffel;
Geoff Eldridge has collected at

http://www.progsoc.uts.edu.au/~geldridg/eiffel/liberty/v1/n1/bm/bmdbc.html

two messages posted in response, one by James McKim and
one by me, which tried to ascertain what is new and what
comes from earlier work. Also, the final sections
of the chapters on Design by Contract and exceptions in
"Object-Oriented Software Construction" have detailed
bibliographical discussions of earlier publications on related
topics.	

-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download
== ISE Eiffel 4: Eiffel from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Jon S Anthony]

In article <33F3C21D.ABD322C@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

> Jon S Anthony wrote:
>  
> > There is nothing new about assertions or the notion behind
> > [Design by Contract].  The basic ideas have been floated in
> > various forms for a looonnggg time now.
> 
> If this is what the discussion finally amounts to, it is hard

It is simply a statement of fact.  Do you have a problem with that?  I
was NOT making a value judgement - that seems to be your province.


>  	just as inevitable is the well-known three-step sequence
> 	of reactions that meets the introduction of a new
> 	methodological principle: (1) "it's trivial"; (2) "it
> 	cannot work"; (3) "that's how I did it all along anyway".

This, of course, is completely irrelevant.


> I guess we have reached the third step now.

One would have to go through 1 and 2 first - for which you'd have to
have a "what".  But, generally speaking, I've claimed it is more
difficult than you.  Of course, to be fair, the "what" has been
typically ill defined in this "debate" and so it is not clear what any
of 1, 2, or 3 even refer to in this context.  Typical.


> More seriously, it is absolutely correct that Design by
> Contract is based on ideas that have been around for a long

Which is ALL I said.  Where's your evidence that I said anything
else??  It would be nice if you were to start following your own
advice and stop blindly impugning the statements of others.  Or do you
feel that you are above such advice?

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Critique of Ariane 5 paper (finally!)

[Robert S. White]

In article <33F22AD8.41C67EA6@eiffel.com>, Bertrand.Meyer@eiffel.com says...
>
>It seems that the idea of using modern techniques to
>improve software reliability shocks some people so much
>that they will find no argument too low in their effort
>to suppress it. Won't work.
> 
  This seems to me to be stooping a bit low.  I am more than willing
to use new "validated" methods of improving/doing software engineering.
That is why the company I work for decided it was very worthwhile to
implement the CMM (now independently certified to level 3) and 
ISO-900x (again independently certified).  I have been able to take
company funded courses in OOA, OOD and software inspections taught
by outside contractors brought it just for the course.  I am using 
the UML to document the high level software design of the hard
real time project that I have been working on for the last few
months.  Convince me of the techinical merits of this new engineering
approach/tool/method for my problem domain and I will most willingly
use it.  All(most?) of us engineers are inherently lazy and _want_ 
to use the most error free, efficient, high quality design 
techniques that gain us satisfaction of a job well done.  A job 
poorly done will come back to haunt you unless you change jobs often.
Some of us don't.  We have been taking a very thorough look at JAVA 
technologies and are already committed to making the JVM and JAVA byte
code work well for our applications.

  Argue your position on its technical merits and please do not make
broad generalizations about the motives of authors of critiques of
your statements.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Robert S. White wrote:
> 
> In article <33F22AD8.41C67EA6@eiffel.com>, Bertrand.Meyer@eiffel.com says...
> >
> >It seems that the idea of using modern techniques to
> >improve software reliability shocks some people so much
> >that they will find no argument too low in their effort
> >to suppress it. Won't work.
> >
>   This seems to me to be stooping a bit low. 

More to the point, it evades the issue.

>   Argue your position on its technical merits and please do not make
> broad generalizations about the motives of authors of critiques of
> your statements.

This appears to be a lost cause. I've never received a response to
any requests of this type (beyond the "you silly engineers don't
understand the Truth if you see it" pap).

Hell of a way to run a business -- if there is such a thing as an
Eiffel business; after the last message from On High, I can't say
for sure :)

> _____________________________________________________________________
> Robert S. White         -- An embedded systems software engineer

Re: Critique of Ariane 5 paper (finally!)

[Robert Dewar]

In article <33F22AD8.41C67EA6@eiffel.com>, Bertrand.Meyer@eiffel.com says...
>
>It seems that the idea of using modern techniques to
>improve software reliability shocks some people so much
>that they will find no argument too low in their effort
>to suppress it. Won't work.


Obviously this is a red herring, since no one acts that way. But I suspect
what we have here is

(a) I have a wonderful method, look here ...
(b) My goodness, you guys aren't using my method ...
(c) The only explanation I can think of is the above paragraph

(a) and (b) OK, but (c) is hardly a clear conclusion :-)

No one is trying to suppress anything, they are just being skeptical of
the claims you are making. If you do not expect such skepticism, then
you really have eebn too walled up in the ivory tower! But really you
perfectly well know enough of the real world to know that new techniques
are a hard sell, if nothing else because most of them are over-hyped and
either not nearly so useful as advertised, or useless, or even actively
unhelpful. It is no surprise for people to be skeptical!

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Bertrand Meyer wrote:
> 
> Samuel Mize wrote:
> 
> > > But to make the jump from sufficient to necessary is completely
> > > without basis, and can only be regarded as advertising puffery.
> >
> > Which appeared in a column in IEEE Computer magazine, positioning
> > it deceptively as a technical item instead of an ad.

As stated this was too strong, and I apologize.

> This is outrageous. ...
> Is any argument for CORBA, or OLE, or UML, or
> Unix, or Windows to be dismissed as as "deceptive",
> an "ad" and not a "technical item"?

In the part of my message you deleted, I stated my opinion that
your paper's conclusion is based on a severely and plainly false
premise.  It was on the basis of that that I dismiss it as being
an "ad" and not a "technical item."

I should have said that its appearance in IEEE Computer gives it
a cachet which may mislead people about its quality and objectivity.

I did not intend to suggest an intent to deceive on your part.
This is why I said the placement, not the author, was deceptive.
Again, I apologize.


> It seems that the idea of using modern techniques to
> improve software reliability shocks some people so much
> that they will find no argument too low in their effort
> to suppress it. Won't work.

Fortunately true.

Samuel Mize

Re: Critique of Ariane 5 paper (finally!)

[Thomas Beale]

Samuel Mize wrote:
> 
> Bertrand Meyer wrote:
> > This is outrageous. ...
> > Is any argument for CORBA, or OLE, or UML, or
> > Unix, or Windows to be dismissed as as "deceptive",
> > an "ad" and not a "technical item"?
> 
> In the part of my message you deleted, I stated my opinion that
> your paper's conclusion is based on a severely and plainly false
> premise.  It was on the basis of that that I dismiss it as being
> an "ad" and not a "technical item."

With this point of view you would consign centuries of vigorous
intellectual debate in all domains of knowledge to the dustbin.
I wonder what Plato would have thought, if you, rather than including
your judgements of his theories (no matter how extreme your 
disagreement) in the debate at the time, tried to paint them
as product advertisements?

If you don't like Bertrand Meyer's opinions, fine. We respect your
right to contribute to the debate also. But don't try and pervert
it by calling the bits you don't like "non-debate". For one thing,
it damages any hope you have as being heard as a credible 
contributor yourself.

- thomas beale

Re: Critique of Ariane 5 paper (finally!)

[Samuel Mize]

Thomas Beale wrote:
> With this point of view you would consign centuries of vigorous
> intellectual debate in all domains of knowledge to the dustbin.
> I wonder what Plato would have thought, if you, rather than including
> your judgements of his theories (no matter how extreme your
> disagreement) in the debate at the time, tried to paint them
> as product advertisements?

I'm not talking about his theories (DBC/Eiffel).  I'm talking about
the quality and content of one specific paper.  In that context it
IS appropriate to characterize the paper.

Specifically, I'm talking about its misstatement of OTHER
PEOPLES' practices.

The paper claims DBC/Eiffel is THE ONE method that could have
found the Ariane 5 flaw, and that current methods did not.  But
the appropriate methods WERE NOT USED.  The Ariane 5 crash does
NOT demonstrate the inadequacy of current practice.

The paper raises and kills a straw man.  It thus fails to qualify
as a technical argument.

It seems to me, this should have been apparent to the authors:

* They have apparently read the ESA analysis, which lists several
  accepted and common methods that WOULD have uncovered the flaw.

* To publish a paper critical of current practice in the
  development of mission-critical and life-critical software,
  it would be appropriate to investigate just what the current
  practice IS in that field.  Postings by people in that field
  have made clear that the Ariane 5 INS reuse was NOT an example
  of "widely accepted industry practices" in this field.

Had he claimed that DBC/Eiffel was one of several methods that
could have averted the disaster, I would consider his paper weak
but technically competent.  Instead he asserts: "To attempt to
reuse software without Eiffel-like assertions is to invite failures
of potentially disastrous consequences."  "For reuse to be
effective, Design By Contract is a requirement."

Since, in my opinion, these absolutist claims are supported ONLY
by raising and killing a straw man, and the authors should have
realized this, I cannot consider the paper a valid technical
contribution.  It seems to be either advertising fluffery or
evidence of complete ignorance about technical debate.  It seems
less insulting to consider it the former.

Both you and Mr. Meyer are responding to a perceived attack on
DBC/Eiffel.  I have made no such attack.  I have stated my
opinion that DBC/Eiffel is ONE method that might have caught
the Ariane 5 flaw.  However, the paper claims that ONLY Eiffel
could have caught the flaw, and this is (in my opinion) an
irresponsible denigration of the standard practices of a lot
of my colleagues.

Samuel Mize

Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer]

Samuel Mize wrote as part of his response to Thomas Beale:
 
> The paper claims DBC/Eiffel is THE ONE method that could have
> found the Ariane 5 flaw.

The paper in question (Jean-Marc Jezequel and Bertrand Meyer,
"Design by Contract: The Lessons of Ariane", IEEE Computer,
January 1997, pages 129-130, slightly revised version at
http://www.eiffel.com) says no such thing, which would be silly.
Once you have discovered a bug, you can usually think ex post
facto of many "methods" that "could" have found it --
some technical (such as Design by Contract), some 
organizational (more design/code reviews, more testing
etc.).

What the paper says (going into the details, and drawing
the lessons) is that reuse without a contract is folly,
and that such improper reuse was the direct cause of the
Ariane failure.

I don't see the point of criticizing people for something
else than what they wrote, especially when the text is
available for everyone to read. 
 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with downloading instructions
== ISE Eiffel 4: Eiffel from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Jon S Anthony]

In article <33F48C0B.41C67EA6@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

> What the paper says (going into the details, and drawing the
> lessons) is that reuse without a contract is folly, and that such
> improper reuse was the direct cause of the Ariane failure.

That's about as interesting as saying "the sky is blue".  And about as
controversial.  So, given that the "paper" has set off (unfortunately)
a controversy, it would appear that the paper is either a) rather
opaque or b) says something more (or less, depending on you POV) than
this.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Critique of Ariane 5 paper (finally!)

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Samuel Mize wrote as part of his response to Thomas Beale:
> 
> > The paper claims DBC/Eiffel is THE ONE method that could have
> > found the Ariane 5 flaw.
> 
> I don't see the point of criticizing people for something
> else than what they wrote, especially when the text is
> available for everyone to read.

Very true. See section 2 of

  http://www.flash.net/~kennieg/ariane.html

for the specific quote from the Eiffel paper that substantiates
Mr. Mize's position.

(By the way, has anyone seen if this link has been placed on
www.irisa.fr or www.eiffel.com?)

> 
> --
> Bertrand Meyer, President, ISE Inc.
> ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
> 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
> http://www.eiffel.com, with downloading instructions
> == ISE Eiffel 4: Eiffel from those who invented it ==

Re: Critique of Ariane 5 paper (finally!)

[Marinos J. Yannikos]

In article <33EB754E.446B9B3D@eiffel.com>, Bertrand Meyer wrote:
>[...]
>There is no such implication, which would be foolish.
>Microsoft has said they would not support the Java Foundation
>Class libraries. This does not mean they are not making
>Java itself available; but it does break the myth of total and
>automatic Java portability.

Since the JFC are written in 100% Java, Microsoft couldn't prevent them
from working unless they didn't offer "Java" (but something resembling it
only, instead). However, to my knowledge, the dispute between Microsoft
and Sun is focused on Microsoft's announcement to make sure that Java
"works best or only" on their operating systems, thus intentionally
breaking its portability. The article on news.com about this was 
strange, since the actual wording went similar to this: "we, Microsoft
will make sure blah blah... but the death of Java's portability is
inevitable anyway, i.e. they seemed to justify their plans with the
inevitability of their effects (even though noone else had announced 
such intentions at that time).

In any case, "total and automatic portability" is a bit vague, since it
doesn't clarify whether you mean the design or the implementation. The
design itself is mostly (sadly, not entirely, as some of the details
in the Core API are implementation-dependent as far as I can tell)
portable. I don't think that intentionally non-portable implementations
can change that. (besides, in Microsoft's case, there's always the
JDK and JWS for Windows from Sun to run JFC programs on)

-nino
-- 
Please change the last part of my address to "at" if you're replying by mail.