home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / unix / 488 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  3.1 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: johnl@iecc.cambridge.ma.us (John R. Levine)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX - Caving In Under Its Own Weight (Long
  5. Date: 26 Dec 1992 14:24:04 -0800
  6. Organization: I.E.C.C.
  7. Lines: 51
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1him24INNfct@ftp.UU.NET>
  11. References: <1hdn66INNi18@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  16.  
  17. >the GKS LIS proved you could write Fortran programs in any language.
  18.  
  19. There's another kind or program?  Uh oh.
  20.  
  21. I think we need to step back a little and consider what appears to me to
  22. be the root of all the standardization trouble: standards should codify
  23. existing practice, or at worse choose from among a few existing versions
  24. of existing practice, perhaps with some minimal glue where the selected
  25. versions don't match up perfectly.  Invented standards usually fail.  ANSI
  26. C came close to the existing practice ideal except for the locale glop
  27. which, not surprisingly, is the least satisfactory part of the C standard.
  28.  
  29. What the GKS LIS really proved, of course, is that we don't know how to
  30. design usable libraries other than by experimentation, and that a suitable
  31. design for one language is probably not a suitable design for another.
  32. These are interesting and useful lessons, but not very helpful for
  33. practical standards design except as a warning of what not to do.
  34.  
  35. POSIX .1 and .2 did a reasonable job of codifying existing practice,
  36. because there was (not by accident) a lot of existing practice to codify
  37. so it looks like they'll be fairly successful.
  38.  
  39. The problems that people have pointed out with the POSIX tests demonstrate
  40. that it is not appropriate to standardize test suites, particularly not
  41. test suites that haven't themselves been tested by a significant amount of
  42. use.
  43.  
  44. I'm all in favor of test suites.  I think there should be lots of them,
  45. since they make the implementor's design so much easier, and raise the
  46. user's confidence that a product that passed the tests probably works.
  47. But test suites make poor standards.  When I was writing an early F77
  48. compiler in 1978-79 (INfort, if anyone remembers if) the compiler passed
  49. most of the tests long before I would have asked anyone to use it on real
  50. code.  The tests were useful, but hardly definitive.  There were places
  51. where the test suites were just wrong, even though they'd been in use for
  52. many years to validate F66 compilers.
  53.  
  54. The argument may be made that various pressures require various sorts of
  55. standards do allow competitive procurement and the like.  I don't believe
  56. it.  A really bad Fortran POSIX binding would in practice mean that nobody
  57. would write POSIX interface code in Fortran, but would more likely write
  58. the interface in C and use some C to Fortran hack.  Ada is admittedly a
  59. special case, given its dedicated customers, but even there a bad enough
  60. standard would force people to circumvent it.
  61.  
  62. Regards,
  63. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  64.  
  65. Volume-Number: Volume 29, Number 98
  66.