From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.c:26806 comp.lang.ada:3421 comp.software-eng:3149 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!grebyn!ted From: ted@grebyn.com (Ted Holden) Newsgroups: comp.lang.c,comp.lang.ada,comp.software-eng Subject: A Poor Man's Ada Library Message-ID: <19452@grebyn.com> Date: 12 Mar 90 02:14:51 GMT Followup-To: comp.lang.c Organization: Grebyn Timesharing, Vienna, VA List-Id: 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