From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Critique of Ariane 5 paper (finally!)
Date: 1997/08/16
Message-ID: <dewar.871741128@merv>#1/1
X-Deja-AN: 264582254
References: <33E503B3.3278@flash.net> <dewar.870870888@merv>
 <33E8FC54.41C67EA6@eiffel.com> <33E9B217.39DA@flash.net>
 <33EA5592.5855@flash.net> <33EB4935.167EB0E7@eiffel.com>
 <33EB754E.446B9B3D@eiffel.com> <33EBE46D.2149@flash.net>
 <33EF9487.41C67EA6@eiffel.com> <dewar.871389016@merv>
 <33F22B91.167EB0E7@eiffel.com>
Organization: New York University
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-08-16T00:00:00+00:00
List-Id: <comp.lang.ada>


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