home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / programm / 3384 < prev    next >
Encoding:
Text File  |  1992-12-31  |  1.8 KB  |  40 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!csus.edu!netcom.com!nagle
  3. From: nagle@netcom.com (John Nagle)
  4. Subject: Re: Programming by Description of Output...
  5. Message-ID: <1993Jan1.043329.27160@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <1992Dec30.174004.4168@cs.cornell.edu> <C036t1.KCH@phage.cshl.org>     <BEVAN.92Dec31001940@panda.cs.man.ac.uk>     <1992Dec31.155736.29068@cs.cornell.edu> <BEVAN.92Dec31202001@panda.cs.man.ac.uk>
  8. Date: Fri, 1 Jan 1993 04:33:29 GMT
  9. Lines: 29
  10.  
  11.      It's a beguiling idea, but it doesn't scale up well.  We went through
  12. this back when formal specifications were being touted as the next big
  13. thing.  It works well for a few simple cases:
  14.  
  15.       1) The inverse of a function is much simpler to implement than 
  16.          the function.
  17.      Example: square root.
  18.  
  19.       2) The function has a simple but inefficient implementation that
  20.      can be used as its description.
  21.      Example: lookup-type operations, including relational databases.
  22.  
  23.       3) The function can be well-expressed by a few constraints.
  24.      Example: sorting.
  25.  
  26. Unfortunately, not many applications seem to fall into these categories.
  27. Our experience in building an operating system this way was that the formal
  28. spec was about 1/3 to 1/2 the size of the code, and much harder to debug.
  29.  
  30. However, if I were doing a database management system, or anything that
  31. basically stores and retrieves data, I'd consider specifying it formally
  32. in terms of its inputs and outputs.  But it might be easier to write a
  33. "dumb" implementation, with everything in arrays and all lookups by 
  34. brute-force search, and use that as a specification.  Formal specs
  35. that you can't run are tough to work with.
  36.  
  37.                     John Nagle
  38.  
  39.                     John Nagle
  40.