Re: Ada Readability, Book Reference

[alex@MIMSY.CS.UMD.EDU (Alex Blakemore)]

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
> "Is Ada readable if you can express an indeterminate program using it?".

Any language that supports concurrency must allow indeterminate programs
to be expressed in that language.  Indeterminate order of execution of specific
 tasks
is a necessary consequence of concurrency.  The most that a language can do
is provide robust and efficient mechanisms for keeping (mostly) independent
tasks (mostly) independent - so that programmers can reason effectively about
the program's possible behavior.  Ada does this fairly well, and Ada9X is even 
better.
Ada9X also tightens the rules in several areas not involving concurrency so tha
t
program behavior is more uniformly specified (bounded) in several previous grey
 areas.

Nonetheless, IMHO you can write readable or unreadable code in any language.
Ada encourages readable software, especially with the strong division between
package interface and implementation.  Some Ada programmers actually hurt reada
bility 
by equating verbosity 100% with readability.  So a program is readable or not, 
a language
can only influence readability to a degree.  Ada excels at this, but the standa
rd that
"readability = inability to express an indeterminate program" is the wrong appr
oach.

Finally, I've recently looked at some C code that was hand translated line by l
ine
into Ada.  The C code was pretty readable and better than most - the Ada was ap
palling.
I think these are the reasons.

  1. The C standard for readability is lower.  The difference between module sp
ecs and
     implementation is much fuzzier.  Global variables are considered normal.
     So things that looked normal in C, looked appalling in Ada where I am used
     to a much more careful statement of what's an interface, what's visible et
c.

  2. The languages are different - and though some aspects of readability are
     fairly independent (use descriptive names), other idioms depend in subtle 
ways
     on the language and its culture.  Good LISP style may be bad Ada style.

  3. The human translator did not seem to know Ada well, so even when doing
     line by line translation - did not choose the best Ada constructs for doin
g
     the little things (loops instead of slice assignments for example) irregar
dless
     of being stuck with the previous decomposition into modules.

Bottom line - readability depends on many things.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted