A Poor Man's Ada Library

[Ted Holden]

     I have come to believe that a good Ada Language library can be
had with very little expense;  everything you need to know about
Ada can be found in three books, if you know how to pick the three. 
Here is my impression of the three books you'll need:
 
 
1.   Ada advocates talk a great deal about "software engineering",
often as if Ada and software engineering were near synonyms. 
Hence, the first book which should be on your shelf should be a
REAL software engineering book.  I recommend Bertrand Meyer's
"Object-Oriented Software Construction", Prentice-Hall
International Series in Computer Science.  Meyer mentions Ada
several times, but only as a bad example, e.g. page 60:
 
     "Because the term 'Object-Oriented' has been used to describe
     various techniques - even Ada has been claimed to be an
     object-oriented language! - it is useful to distinguish the
     various steps that lead to true object-orientedness."
 
Object-oriented programming is the only thing which could possibly
help some of the giant projects which are now mandated to be done
in Ada.  Ada doesn't have it now.  Ada probably won't have it with
the 9x version, which will likely include mostly fixes for some of
the present bugs and woes, and given the speed of the process
involved, the 9x standard will probably be out in about a year, a
first compiler in four years, and first near-reasonable compilers
in seven or ten years.  This probably says 14+ years for object-
oriented Ada.
 
 
2.   Another term which software engineers, particularly of the Ada
variant, are constantly blathering about is "software reusability". 
Hence, the second book in your Ada library should be a "software
reusability" book.  This, I figure, just has to be the Programmers'
Connection catalogue, which can be had free for a phone call to
(800 336-1166).  This catalogue has everything under the sun in it,
at least for the mini-micro/UNIX world, and that about says it all
these days, or at least says most of it.  A programmer with this
catalogue at his disposal can regard his C compiler as a tube of
glue with which to simply glue things from the catalogue together; 
that makes for a kind of an easy life.  The catalogue also contains
a few Ada items for perverts, but you will notice that it contains
three indices, one by company, one by product name, and one by
function, and that the function index contains about a fifth of a
column on Ada and several pages on C products.  Hence, in the book
on software reusability, Ada is basically a footnote, and C is the
body of the book.
 
 
3.   Of course, I've been saving the good part for last.  The third
book you will need for your Ada library is a real, honest-to-God
Ada book, and here we delve into the realm of humor.  All Ada books
are funny to some extent or other, but my choice will have to be
one pointed out to my by my buddy Harris Reavin:  "Software
Development With Ada", Addison Wesley International Computer
Science Series, by Ian Sommerville and Ron Morrison.  The back
cover reads:
 
     "The effective use of the Ada programming language will make
     a dramatic difference to the cost and quality of real-time
     software systems.  The aim of this book is to promote an
     understanding of the concepts which underlie the language
     facilities of Ada."
 
Sounds good, so far, but reading between the covers quickly leads
to high humor:
 
Page 21
 
     "Ada programmers have to be more highty skilled than
     programmers in FORTRAN or assembly code because they must
     understand the concepts underlying Ada to use the langnage
     properly. This means that they probably expect to be paid more
     for their sewices, thus increasing implementation costs."
 
Ada "gurus" are constantly talking about the advantage of Ada for
team projects, but here Sommerville/Morrison are making the point
that the do-everything language is so complex that the only team
likely to succeed at doing anything at all with it is the local
chapter of Mensa.
 
 
Again, on pages 22 - 23
 
     "There is no question whatsoever that the biggest problem in
     changing from Pascal, FORTRAN, or assembly langnage
     programming to Ada is posed by the sheer size of the Ada
     language. Indeed, it has been argued by Hoare (1981) that Ada
     is so large and so complex a language that it will be
     impossible ever to have confidence in its implementation.
 
     Therefore, the use of Ada might actually reduce software
     reliability.  Hoare's argument is flawed as, whatever its
     faults, Ada is better than assembly language, which is often
     the only altemative. However, we accept that Ada is a large
     and complex language which could and should be trimmed in some
     areas...
 
     Furthermore, the effective use of Ada constructs, such as
     packages, to implement abstract data types, requires an
     understanding of the concepts that underlie these constructs.
     This implies that the effective use of Ada requires some
     formal training in computer science, and this will pose
     immense problems Ior those organizations whose software
     engineers do not have such a background. This is a fairly
     common situation, and very large training costs must be
     budgeted for in the management of a transition to Ada as the
     principal programming language for systems development."
 
 
What do Sommerville/Morrison have to say about the likelihood of
ever actually hiring the local Mensa chapter as your programming
team out on some military base in Muskogee Oklahoma?
 
On page 37
 
     "The lnterLisp system is an excellent example of a tightly
     integrated programming environment, but it is unlikely that
     environments to support the development of programs in other
     languages, such as Ada, can be integrated in the same way. Not
     only is language extension forbidden in Ada, but the Ada
     programming community will exhibit a wider range of abilities
     than the InterLisp community who are all highly skilled
     programmers.  Less skilled and motivated workers are not
     likely to be willing to expend the time required to learn
     about a complex, extensible programming environment.  Nor are
     they able to produce powerful tools to extend that
     encironment.  So, although Ada-oriented programming
     environments may be built, they are unlikely to be as tightly
     integrated as InterLisp"
 
Does this contradiction sound a little bit more serious than the
problem concerning the inner meaning of "break" in C?
 
Sommerville/Morrison have more to say about Ada:
 
Page 43
 
     "Although it is to the credit of the planners of Ada that the
     need for a support environment was recognized, less time and
     effort were expended in establishing the requirements for that
     environment than were spent in the formulation of the langnage
     requirements. This was probably a mistake as sofarare
     engineering tools are as important a part of the soltware
     development process as the programming language used. In fact,
     had the APSE and Ada been designed as an integrated system,
     some of the complexity inherent in Ada might have been
     factored out into the APSE."
 
 
Page 69
 
 
     "A particular problem with using Ada as a design description
     language is that all dependencies (with clauses) must be
     specified before the program can be compiled. This conflicts
     with top-down design where high-level decisions are made and
     dependencies sorted out at a later stage.
 
 
Page 177
 
     Ada has limited facilities for inheritance and it has been
     argued that it is not a true object oriented programming
     language because of this lack.  However, as we shall see
     later, derived types and packages together do give some form
     of inheritance.
 
 
Page 204
 
     ...As we have said before, the subroutine is the main
     abstraction facility in Ada.
 
 
Page 219
 
     "...For example, if a package specification is recompiled,
     then so must be the package body, even though it is not
     altered.  The same is true for all sub units of library units,
     and may cause considerable recompilation.
 
Which makes for lots of slow, given what everybody knows to be the
case concerning Ada compile times. 
 
 
 
Ted Holden
HTE