Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site scirtp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!harpo!whuxlm!akgua!mcnc!rti-sel!scirtp!scott
From: scott@scirtp.UUCP (Scott Crenshaw)
Newsgroups: net.ai
Subject: Re: Program Specification Languages
Message-ID: <395@scirtp.UUCP>
Date: Wed, 4-Sep-85 23:41:12 EDT
Article-I.D.: scirtp.395
Posted: Wed Sep  4 23:41:12 1985
Date-Received: Sat, 7-Sep-85 04:43:55 EDT
References: <638@wdl1.UUCP> <629@mmintl.UUCP>
Organization: SCI Systems, Research Triangle Park, NC
Lines: 19

> 
> 
> The whole idea of a specification language for a computer program is flawed.
> If the specification is good enough to really determine what the program
> does, it IS a program; only the compiler is missing.  If it isn't that good,
> why bother with a formal specification language?  (Do write a specification,
> of course; just don't expect it to be good enough for a verification.)

	I agree. However, I think efficiency considerations play an important
part in the current state of affiars. Most specification languages simply 
can't be translated efficiently enough for production work on current 
architectures. Furthermore, once a formal specification is validated, 
implementation issues can be resolved by people whose experience lies in
conventional programming languages . There aren't many people experienced 
in specification languages. 

-- 
	-- Scott Crenshaw		{akgua,decvax}!mcnc!rti-sel!scirtp
	   SCI Systems , Inc. 		Research Triangle Park, NC