Re: 30 Years

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

In article <26qc0u$k0b@louie.udel.edu> carroll@gloin.cis.udel.edu (Mark C. Carr
oll) writes:

  > This is made even worse by the way in which Ada documents describe the
  > language. I got the annotated reference manual for Ada9x, and went to
  > print it out. How long could it possibly be? I use languages similar
  > to Ada all the time, and the manuals are between 30 and 100 pages
  > long. The Ada manual is over *500* pages, the overwhelming majority of
  > which is bureaucratic twaddle. 

     How many programming language standards have you read?  The
Pascal standard is small and readable, but, for example, the Algol 68
standard probably wins all the prizes for obscurity and
impenetrability, the size of the PL/1 standard (not PL/1 subset G)
makes the Ada standard look like light reading, and (not to ignore
popular languages) the COBOL RM easily surpasses even the AARM in
bureaucratic twaddle (and size for that matter).

     Language standards are usually designed to be read only by
compiler implementors.  Ada broke that tradition by having a reference
manual that really was laid out for users of the language to
reference.  But it was certainly not intended to be an introductory
textbook.  In Ada 9X, the RM is still intended for users, and the AARM
is a bonus document (replacing the Ada 83 Implementors Guide) to help
compiler writers.

   > It was certainly enough to drive *me* away. I'd like to use Ada.
   > But when it comes down to writing an implementation, and I need
   > to know every detail of what's interacting with my extensions, I
   > can't afford to search through an overblown, oververbose, overly
   > bureaucratic manual, hoping that I don't miss anything.

   Let me guess, you much prefer the Oberon manual, or any others of
the species, where you don't have to worry about missing all those
details, because they aren't in the manual.  The interactions are
still there, it's just that the reference manual ignores them.  (Flame
protection...there is no reason for the author of a language AND a
compiler to put ANYTHING about implementation tricks and interactions
anywhere other than in comments in the compiler.  That is only
necessary much later when there are several different root compilers
for the same language.)
   
   > I'm still looking forward to having GNAT. I'd like to be able to
   > program in Ada, and I expect I'll use it a lot, once I have
   > access to a decent compiler. But I won't use it for my research.

   Are you sure you don't have access to a decent Ada compiler?  UDel
is a pretty large place.  (If Bob Cavendish is still there say hi for
me.)

   > Too many Ada haters try to say that it's a lousy language, and
   > that everything about it stinks. But too many Ada lovers refuse
   > to acknowledge the problems in the language and its presentation,
   > and try to blame everything on the Ada haters.

     Which group do you put yourself in?  I think I qualify as an Ada
lover, but I don't try to blame Ada haters for the flaws in the RM, I
try to fix them.  If you think there are places where the AARM can be
cleaned up, send your comments in.  (But you should probably wait for
the next version of the AARM which should be ready in a week or two.)
   
     There was a lot of discussion on this subject (the apparent
complexity of the standard) at the August meeting, and some progress
was made, but if you have any ideas about how to make the presentation
less daunting, let Tucker know.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...