home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / ada / 3837 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.9 KB
  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!darwin.sura.net!dtix!mimsy!alex
  2. From: alex@cs.umd.edu (Alex Blakemore)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: Ada Readability, Book Reference
  5. Message-ID: <63088@mimsy.umd.edu>
  6. Date: 29 Dec 92 19:35:14 GMT
  7. References: <9212281507.AA20416@ajpo.sei.cmu.edu>
  8. Sender: news@mimsy.umd.edu
  9. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  10. Lines: 41
  11.  
  12. In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
  13. > "Is Ada readable if you can express an indeterminate program using it?".
  14.  
  15. Any language that supports concurrency must allow indeterminate programs
  16. to be expressed in that language.  Indeterminate order of execution of specific tasks
  17. is a necessary consequence of concurrency.  The most that a language can do
  18. is provide robust and efficient mechanisms for keeping (mostly) independent
  19. tasks (mostly) independent - so that programmers can reason effectively about
  20. the program's possible behavior.  Ada does this fairly well, and Ada9X is even better.
  21. Ada9X also tightens the rules in several areas not involving concurrency so that
  22. program behavior is more uniformly specified (bounded) in several previous grey areas.
  23.  
  24. Nonetheless, IMHO you can write readable or unreadable code in any language.
  25. Ada encourages readable software, especially with the strong division between
  26. package interface and implementation.  Some Ada programmers actually hurt readability 
  27. by equating verbosity 100% with readability.  So a program is readable or not, a language
  28. can only influence readability to a degree.  Ada excels at this, but the standard that
  29. "readability = inability to express an indeterminate program" is the wrong approach.
  30.  
  31. Finally, I've recently looked at some C code that was hand translated line by line
  32. into Ada.  The C code was pretty readable and better than most - the Ada was appalling.
  33. I think these are the reasons.
  34.  
  35.   1. The C standard for readability is lower.  The difference between module specs and
  36.      implementation is much fuzzier.  Global variables are considered normal.
  37.      So things that looked normal in C, looked appalling in Ada where I am used
  38.      to a much more careful statement of what's an interface, what's visible etc.
  39.  
  40.   2. The languages are different - and though some aspects of readability are
  41.      fairly independent (use descriptive names), other idioms depend in subtle ways
  42.      on the language and its culture.  Good LISP style may be bad Ada style.
  43.  
  44.   3. The human translator did not seem to know Ada well, so even when doing
  45.      line by line translation - did not choose the best Ada constructs for doing
  46.      the little things (loops instead of slice assignments for example) irregardless
  47.      of being stuck with the previous decomposition into modules.
  48.  
  49. Bottom line - readability depends on many things.
  50. -- 
  51. ---------------------------------------------------
  52. Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
  53.