Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!tgg
From: tgg@otter.hpl.hp.com (Tom Gardner)
Newsgroups: comp.specification
Subject: Re: Against executable specifications (Re: specifying OBJ in itself)
Message-ID: <28190001@otter.hpl.hp.com>
Date: 23 Oct 90 07:58:10 GMT
References: <4955@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 23

A couple of points:
	- just because an executable specification language/system cannot
	cover all points does not make it useless
	- there are many problems for which an executable specification
	would greatly improve the quality of the resulting system
	- even if you have a rigorous complete and self-consistent version
	of a system (and you can add any other hooray words that you like
	to this list), how would you know that 
		(a) the _specification_ is correct 
		(b) the specification accurately reflects what will occur
		in the real world 
		(c) the specification is what the user/customer wants
	- every program that I have ever written or will ever write is an
	executable specification

What I want is any tool which will improve the quality of the end system:
I am not too concerned if it can't tackle _every_ problem (I'm not going to 
use a shovel to dig theChannel Tunnel, nor am I going to use a tunnel-boring
machine to dig my vegetable garden).

Yes, I do realise that I am subtly misunderstanding/misinterpreting some of
the concepts behind "executable specifications". I do this so that the baby
isn't thrown out with the bathwater.