Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <5151@stpstn.UUCP>
Date: 2 Jun 90 16:50:25 GMT
References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <5132@stpstn.UUCP> <19948@duke.cs.duke.edu>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 65


In article <19948@duke.cs.duke.edu> crm@romeo.cs.duke.edu (Charlie Martin) writes:
<    [T]he common-sense meaning of these terms is precisely the meaning
<    that I've been using. An implementation is *correct* if it complies
<    to its *specification* within an acceptable tolerance. There's
<    nothing mathematical about it. 
<
<Come on Brad, you're contradicting yourself in-line, here.  "...within
<an acceptable tolerance" is a mathematical statement, and it's
<interpreted as such in ANY form of engineering.  If I design a gear and
<I want it milled to within one-one-thousandth of an inch, I am stating a
<measure, and stating a numerical value against which the measured gear
<can be compared by measuring.  If I want to do QA on gears, I state a
<statistical distribution and acceptable variance.  These are all
<mathematical statements.

Change the example slightly, say to hamburgers, and "tolerance" as to
what is "acceptable" becomes much less obviously mathematical.

I don't want to be pushed into an either/or situation here, because software
really *is* a swamp; a hybrid of land and sea; a nearly 50-50 hybrid between 
the concrete domain of burger flipping and the abstract domain of mathematics.

<So this leads to the implication that Brad is saying that Correctness is
<also something that can't be measured or quantified in any way.  I can
<see the argument, which is one reason that I wish the formal methods
<folks had chosen some other word -- say "compliance" -- for the concept
<of "meets the specification in all cases."  (After all, it is not in
<some sense correct unless the user *likes* it; the only measure for this
<is if they then *pay* for it, and this can be a very indirect one.)
<However, attractive as it is philosophically, it's not a useful idea for
<engineering.  It comes down to arguing that whether or not an
<implementation meets its specification is something that is not
<mathematical, not quantifiable or measurable in any way.  (Notice that
<this excludes *testing* just as much as it does proof).  

No, you're misstating me. My whole point about specification/testing languages
is that we *do* need to start getting as serious about specifying software as
McDonalds is about specifying burgers. Correctness (or quality) *can* be 
measured, but its absolute measure is the satisfaction it brings to its users,
which of course can only be measured by its consumers. Its *producers*, however,
must be satisfied with less technologically appealing indirect measures, since
the absolute measure is technologically intractible (brain probes, anyone?)

<If Correctness really *is* like Persig's Quality, then there is only the
<ability of a trained eye to directly perceive the wondrous Correctness
<of the result of one's engineering efforts.  I don't think that is
<suitable in any kind of engineering: I certainly wouldn't want to drive
<across a bridge whose capacity couldn't be measured.
<
<The difficulty of a purely testing-based approach to "correctness" as
<Brad is apparently advocating, is that we CAN'T in all cases depend on
<the common-sense behavior of the system in question.

Again, I'd never advocate any *pure* approach to anything as impure as swamp.
The point of the paper was that bridges and guns and plumbing systems would be
as problematic as software if we built them as we do software, by having each
plumber mine, refine, and manufacture their own components rather than by
distributing this effort over time and space via a marketplace. As you've
pointed out, marketplaces are not pure approaches. They involve some
mathematics here, some common sense there, some politics yonder, etc, etc.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482