A Poor Man's Ada Library

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
 
 
 
 
 
 
 
 
 
 
 

Re: Ada

[William Thomas Wolfe, 2847]

From article <19452@grebyn.com>, by ted@grebyn.com (Ted Holden):
> 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.

   Regrettably for Mr. Holden, object-oriented Ada is available right
   now.  Software Productivity Solutions has a product called Classic
   Ada which serves as a Smalltalk-based object-oriented preprocessor 
   for Ada-language software developers.  Another object-oriented approach
   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
   market as well.  But Ted Holden will never let reality interfere with 
   his point of view, as he has so repeatedly demonstrated. 

> 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.

   Well, Ted, if you aren't bright enough to handle Ada, I suggest that
   you stay away from it.  However, you should keep in mind that STANFINS-R
   has recently demonstrated that even COBOL programmers can be turned into
   effective Ada software engineers.  Perhaps you should therefore see to it
   that you refrain from using any language more sophisticated than COBOL!
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: A Poor Man's Ada Library

[Peter da Silva]

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

Which language is the best (was Re: Ada)

[Don Allingham]

Ok.  I've been wading though this trash for long enough.  Let's try to
put some reason into this garbage.

To Mr. Wolfe:
 
Just because someone is not writing in ADA, it does not
mean that they are not writing responsible code.  Nor does the fact
that some UNIX programmers like to put cute messages in the man page
mean that all C programmers don't care about bugs.  Please don't do to
comp.lang.c what you did to alt.cobol.  We are here in comp.lang.c to
discuss C, not to listen to rant and rave.

To the Ada bashers:

While I do not know ADA, I am sure that it has its place.  No, it is
probably not perfect.  Neither is C, C++, FORTRAN, PASCAL, LISP, or
Basic.  Face it.  Even with ANSI C, C is still not perfect.  You can
bash ADA all you want, but it will not go away.  Accept ADA as another
alternate language.  Who knows, someday you may find it to be the best
language for an application.

Most (if not all) languages have their place.  I would not write an
operating system in COBOL, but then C is probably not the easiest
language in the world to write a financial program.  Pascal is
supposed to be an educational language, and yes, several good
commercial programs have been written in it (just ask Apple).

Each language has its drawbacks.  That does not mean that it is not
any good.  Where I work, we use many languages, including LISP, C,
C++, Pascal, and FORTRAN.  The code tends to be reliable not because
of the language, but because of the process we use to check quality.

Now please, take this discussion to alt.religion.computers and leave
us to discuss C.

--
Don Allingham           
NCR Microelectronics 			dona@FtCollins.NCR.com
Ft. Collins, CO.        		uunet!ncrlnk!ncr-sd!ncr-fc!bach!dona

Re: Ada

[William B. Tyler]

In article <8322@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   Regrettably for Mr. Holden, object-oriented Ada is available right
>   now.  Software Productivity Solutions has a product called Classic
>   Ada which serves as a Smalltalk-based object-oriented preprocessor 
>   for Ada-language software developers.  Another object-oriented approach
>   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
>   market as well.  But Ted Holden will never let reality interfere with 
>   his point of view, as he has so repeatedly demonstrated. 
>

Wolfe's response serves to reinforce Holden's point.  Ada, the language,
has no capability for object oriented programming.  Use of these 
extensions amounts to use of a different language, especially since 
Ada admits no extensions by definition.

>   Well, Ted, if you aren't bright enough to handle Ada, I suggest that
>   you stay away from it.  

This seems to be an admission that Ada has failed in a very important
area of language design.  If it requires brilliance for proper use,
it is certainly inappropriate as a vehicle for implementing large
projects with many programmers, some at least of whom will be of
average intelligence.

Why don't you give it a rest, Wolfie?  At least try keeping out of
the C newsgroup.
-- 
Bill Tyler				...(tolerant|hpda)!procase!tyler

Re: Ada

[Dennis M. O'Connor]

"[...*...]" below means I've deleted something I consider an ad-hominem,
that IMHO added nothing constructive to the conversation. My apologies
if I offend anyone.

tyler@procase (William B. Tyler) writes:
] In article <...> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
] > [...*...]
] >   Software Productivity Solutions has a product called Classic Ada
] >    which serves as a Smalltalk-based object-oriented preprocessor 
] >   for Ada-language software developers.  Another object-oriented approach
] >   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
] >   market as well. 
] > [...*...]
] 
] [...*...]  Ada ... has no capability for object oriented programming.

My understanding is that "support for OOP" is not a YES-NO question.
IMHO, Ada does support objects, if not OOP : does not a package represent
a passive object, and a task represent an active one ? Doesn't a
"task type" has all the characteristics of a class (and even more) ?
What Ada doesn't support is inheritance. So, Ada's support for OOP
is limited, not non-existant. It's support for Object-Oriented Design
(OOD) is a different issue.

] Use of these extensions amounts to use of a different language, especially
] since Ada admits no extensions by definition.

However, if you believe that the primary benefit of OOP is found in
the design stage (OOD), then using something like Classic Ada for design,
and then automatically translating it into Ada (which is, I believe,
how these products work) is probably an option even in an "Ada-only"
project. (Any DoD project participants care to comment ?) It is certainly
an option for those who use Ada because they like the features of the
language, not because of a DoD mandate. Yes, such people exist. ;-)

] >  [...*...] if you aren't bright enough to handle Ada, I suggest that
] >   you stay away from it.  
] 
] This seems to be an admission that Ada has failed in a very important
] area of language design.  If it requires brilliance for proper use,
] it is certainly inappropriate as a vehicle for implementing large
] projects with many programmers, some at least of whom will be of
] average intelligence.

What is this "you gotta be smart to use Ada" stuff anyway ? Let's
face it : if you are using the complex features of any language, it
should be because the design is complex, not because of the the
language you are implementing in. And if the design is complex,
you'd better be smart no matter what language you use.

If a language forces you to implement a simple design in
a complex way, I`d say it's flawed. Feel free to point
out such flaws in Ada to the Ada-9X commitee, please !

In a large project with programmers of varying degrees of talent,
"average" (yuck I hate that word) programmers should be assigned
tasks of "average" difficulty, and the tough stuff should be
done by the most talented people. This, like many other issues,
is language-independant.

It has to be admitted, of course, that many languages wind up associated 
with a particular design methodology and project management philosophy.
But "correlation is not causation", eh ?

] Why don't you give it a rest [...] try keeping out of the C newsgroup.

I don't really understand the emnity between some of the C and Ada
proponents. Why the emotions ? What are people afraid of ? So
one or both languages doesn't take over the world, so what ?
Eventually (I hope) both will be obsolete in their present forms.
Hopefully, both can learn form each other, and evolve into
something better.

Nobody should mind constructive criticism, eh ?
--
  Dennis O'Connor      OCONNORDM@CRD.GE.COM      UUNET!CRD.GE.COM!OCONNOR
  "Let's take a little off the top ... a bit off the sides ...
    trim the back a bit ... Surprise ! You've been bald-ed !"