Path: utzoo!attcan!uunet!mcsun!ukc!newcastle.ac.uk!colman!des0mpw From: des0mpw@colman.newcastle.ac.uk (M.P. Ward) Newsgroups: comp.specification Subject: Re: Difference between Spec and Code? Message-ID: <1990Oct31.102351.21789@newcastle.ac.uk> Date: 31 Oct 90 10:23:51 GMT References: <21500@dime.cs.umass.edu> <5321@uqcspe.cs.uq.oz.au> <13576@june.cs.washington.edu> Sender: news@newcastle.ac.uk Organization: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU Lines: 36 In article , 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. A secondary attribute of a good specification is separation of concerns. For example: one part of the spec will specify "normal" behaviour, another part will specify the action take under various error conditions. In the implementation the error handling code will be deeply intertwingled with the "normal case" code - but they are logically separate and should be separate in the specification. Another example is a report printing program where one part specifies the headings and record formats and another part specifies the pagenation (lines per page, headers and footers on each page, page count etc.) and perhaps a third part defining the end of report totals as a function of the whole database. In the implementation these will be deeply mixed, with the record formatter incrementing the line count, report totals etc. Martin. JANET: Martin.Ward@uk.ac.durham Internet (eg US): Martin.Ward@DURHAM.AC.UK or if that fails: Martin.Ward%uk.ac.durham@nfsnet-relay.ac.uk or even: Martin.Ward%DURHAM.AC.UK@CUNYVM.CUNY.EDU BITNET: IN%"Martin.Ward@DURHAM.AC.UK" UUCP:...!mcvax!ukc!durham!Martin.Ward