Path: utzoo!attcan!uunet!comp.vuw.ac.nz!lindsay
From: lindsay@comp.vuw.ac.nz (Lindsay Groves)
Newsgroups: comp.specification
Subject: Re: Difference between Spec and Code?
Message-ID: <1990Nov06.020123.29702@comp.vuw.ac.nz>
Date: 6 Nov 90 02:01:23 GMT
References: <21500@dime.cs.umass.edu> <5321@uqcspe.cs.uq.oz.au> <BLK.90Oct25142230@vanity.mitre.org> <13576@june.cs.washington.edu> <1990Oct31.102351.21789@newcastle.ac.uk>
Sender: news@comp.vuw.ac.nz (News Admin)
Reply-To: lindsay@comp.vuw.ac.nz
Organization: Computer Science Dept, Victoria University, Wellington, NEW ZEALAND
Lines: 55
Nntp-Posting-Host: taputeranga.comp.vuw.ac.nz
Originator: lindsay@taputeranga.comp.vuw.ac.nz


In article <1990Oct31.102351.21789@newcastle.ac.uk>,
des0mpw@colman.newcastle.ac.uk (M.P. Ward) writes:
|> In article <BLK.90Oct25142230@vanity.mitre.org>, blk@mitre.org (Brian
|> L. Kahn) writes:
|> > 
|> > For some time, I've puzzled over the difference (if any) between a
|> > specification language and a programming language.  The best I can
|> > come up with is that a spec has less information about data
|> structures
|> > and/or algorithms than is usually found in code.  ...
|> 
|> I always used to say "a specification is more abstract than a
|> program"
|> (there is a continuum here ranging from "low-level" programs to
|> "highly
|> abstract" specifications - its not an either-or relation). Then I
|> was
|> challenged to define what I meant by "more abstract". The best
|> definition
|> I could come up with was SMALLER (and more readable - but the metric
|> which coresponds most closely to intuitive notions of readablility is
|> size!).
|> Naturally, for a specification to be smaller it _has_ to contain
|> less
|> information: the input-output behaviour is arguably the most useful
|> information to a user of the program, therefore the specification
|> will
|> have less (or no) information about data structures and algorithms.

It may be helpful to distinguish between the following questions:
   (i) what kind of text CAN be considered to be a specification/program?
  (ii) what kind of thing you SHOULD write in a specification/program?

If you are concerned with (i), then Brendan's answer (that programs are
the executable subset of specifications) is fine.  If you are concerned
with (ii), that answer is not at all helpful.  In this case you would be
hard pressed to better than the old adage (anyone know who said this
first?): a specification should say WHAT is to be done, not HOW it is to
be done.

Saying that a specification is "more abstract" than a program does mean
that it contains less information.  The whole point, however, is that
the "missing" information is concerned with HOW rather than WHAT, so
(from the specifiers point of view) it is irrelevant.  Such information
should not be part of a specification because it clutters the
specification with unnecessary detail, making it harder to understand,
and because it restricts the range of possible implementations.  This is
precisely the point made in the article by Cliff Jones and Ian Hayes
which someone mentioned a week or so back ("Specifications are not
(necessarily) executable") -- that restricting formal specifications in
such a way as to make them executable restricts their expressiveness and
restricts possbile implementations.

Lindsay