ted@grebyn.com (Ted Holden) (03/12/90)
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
peter@ficc.uu.net (Peter da Silva) (03/12/90)
Thank you for an informative article, but don't you think it would have been
better to redirect followups to the groups in which a discussion of Ada might
be appropriate, rather than the one group for which it clearly isn't? The
Ada versus C war was amusing in it's time, but that time is now long past.
In an attempt to provide a little information, now, here's a couple of quotes
from Charles Anthony Richard Hoare, whose Turing Award speech was directed
at the Ada language:
"There are two ways of constructing a software design. One way is
to make it so simple that there are obviously no deficiencies and
the other is to make it so complicated that there are no obvious
deficiencies."
- C. A. R. Hoare
"Do not allow this language (Ada) in its present state to be used
in applications where reliability is critical, i.e., nuclear
power stations, cruise missiles, early warning systems, anti-
ballistic missle defense systems. The next rocket to go astray
as a result of a programming language error may not be an
exploratory space rocket on a harmless trip to Venus: It may be a
nuclear warhead exploding over one of our cities. An unreliable
programming language generating unreliable programs constitutes a
far greater risk to our environment and to our society than
unsafe cars, toxic pesticides, or accidents at nuclear power
stations."
- C. A. R. Hoare
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ 'U`
\_.--._/
v