Re: The stupidity of all the Ariane 5 analysts.

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Bertrand said

<<>All this is rhetorics and cannot succeed to obscure the basic
>claim that systematic use of Design by Contract would probably
>have avoided the crash.
>>

Well all sorts of things would have avoided the crash. One can also say
that systematic proof of correctness, or systematic code review, or
in fact almost any steps to be a bit more careful in this particular
area, would have avoided the crash. As usual, a disaster of this type
is a chain of occurrences, and fixing any one of them would have avoided
the problem.

Certainly the notion of clear interfaces and interface requirements
(I find the use of the capitalized "Design by Contract" a little 
pretentious, since I see no new concept there that justifies a new
technical term) is one which we can all agree on.

The argument that the use of Eiffel would have prevented the problem is
entirely unconvincing, and has the unfortunate effect of encouraging
people to think that the entire argument is just empty language advocacy.


When there is a major screwup in software (some examples, the long lines
failure at AT&T, the Denver baggage handling, the overnight funds transfer
disaster in an NY bank etc), there is a natural tendency for over
enthusiastic pushers of a particular language to try to argue that
their particular pet language would have guaranteed freedom from the
problem.

Such arguments are never convincing, because even if it *were* the case
that the particular problem at hand might *possibly* have had a better
chance of being avoided writing in language X, extending this to the
allegation that the use of language X would in general have been beneficial
stretches credibility. In particular, in a large complex system of this
type, the language and all other components have to meet all kinds of
complex requirements, and people who know nothing at all about the whole
application have no idea whatsoever if their pet language would in fact
meet the criteria.

If Bertrand is saying:

(a) The Ariane problem (at least little piece of it) is a good example of
why designing interfaces that are complete with respect to establishing
a requirements contract for clients is a good idea.

(b) One of the attractive features of Eiffel is that it supports this
concept directly and encourages programmers to use this approach.

Then the argument is entirely reasonable, and one that I cannot see
anyone objecting to. But the way the argument is stated, it reads as
though he is saying:

If Eiffel had been used for the Ariane project, it would not have crashed.

And I find that claim entirely unjustified, and it detracts from the
important underlying point.

No language can force people to do things right, and to a large extent
no language prevents people from doing things right. What a language
can do is to encoruage a style of programming and thinking that helps
people find their way to doing things right a little more easily.


This is indeed the principle behind the Ada design, and a lot of the
reason that Ada is successful in practice is precisely because it
encourages "good thinking". 

But when people said "if only the Denver baggae system had been written
in Ada, I would be flying to the new airport today", this crossed the
line into non-credible language advocacy.

Similarly, a lot of the thinking behind the Eiffel design is also
to encourage "good thinking", and in that sense Ada and Eiffel are
kindred spirits in their approach to language design, though they
make different choices about what is important to encourage.

However, when the Eiffel advocacy crosses the line to saying that a large
complex system, if written in Eiffel, would have succeeeded where otherwise
it failed, again this crosses the line into non-credible language advocacy.

I am, as everyone knows, a strong advocate of the use of Ada. However, I
take a lot of care NOT to make exaggerated claims, since I don't think
this helps at all. What Ada (or any other language) can do, is to push
programmers up a little bit on the quality and productivity scales.

A little bit may not sound like much, but these scales are logarithmic
scales in which the productivity of programmers and the quality of the
code they right varies over orders of magnitudes, so a "little bit" can
add up to very substantial savings in costs, and very substantial
improvements in quality in practice.