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 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!ucbvax!usc-isif.arpa!EBERARD From: EBERARD@USC-ISIF.ARPA (Edward V. Berard) Newsgroups: net.lang.ada Subject: Is Ada Technology Really Trash? Message-ID: <8603311227.AA28193@ucbvax.berkeley.edu> Date: Mon, 31-Mar-86 07:25:14 EST Article-I.D.: ucbvax.8603311227.AA28193 Posted: Mon Mar 31 07:25:14 1986 Date-Received: Wed, 2-Apr-86 02:43:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: I am writing in response to your message, "Not really unsigned and not trash." While I do not expect that I can change your opinion of Ada technology, some clarifications are in order. Regarding your experience in Ada applications: While there have been a good number of Ada success stories (contact Maj. Al Kopp at the Ada Joint Program Office), there have also been a number of failures. For example, Owen McOmber reported in February of 1985 that the SUBACS program was a failure (the Navy would be lucky, said McOmber, if they could salvage 50,000 lines of Ada code out of an estimated 2,000,000 lines written). McOmber went on to say that "continuing to push Ada for Ada's sake will kill the language." However, McOmber went on to acknowledge that, " the SUBACS failure was due to its ambitious schedule and that it would have failed regardless of the implementation language used." We technologists often have a hard time differentiating between a bad idea and a bad implementation of a good idea. Any concept, including Ada technology, can be implemented so poorly that it appears that the original idea was ill-conceived. Further, since technologists and their managers often have a hard time accepting blame for any failures, it is often convenient to blame inanimate objects (e.g., the Ada programming language) for the failure of a project. (Remember the cliche about a poor workman blaming his tools.) Regarding your breaking of Ada compilers: As recently as this year, I have had experiences with bug-ridden FORTRAN and C compilers. If you meant to imply that only Ada compilers have bugs, or that they are any more bug-ridden than compilers for other languages, you have an almost impossible task. A visit to any computer science department will turn up dozens of students who can break the compilers on the university's compilers (for all programming languages). Quite a lot is demanded of Ada compilers. It has barely been three years since the ANSI/MIL-STD 1815A was established (February 17, 1983). It has been less than three years since the first Ada translator was validated (April 11, 1983). Considering that short time span, I am impressed with the state of Ada compiler technology. [As as exercise for your students, you might have them attempt to establish and compare the maturity of compilers for other languages, e.g., C, LISP, Pascal, and FORTRAN, when they were as old as Ada is today.] If the fact that certain technology originates from the federal government, or from the Department of Defense, offends you, you may find that your offense diminishes with time. It is no secret that the technology associated with items such as airplanes, computers, and computer programming languages (remember COBOL?) was either originated or accelerated when it was deemed to be in the interest of national security. Fortunately, in time, most of the DoD's pet technologies lose their direct association with the DoD and are then evaluated by the masses on their own merits. [You might find it interesting to note that in Europe over 80% of the Ada applications are non-military, or that the Japanese are making extensive use of Ada technology (to my knowledge, none of it for military purposes).] Regarding your comments about the time to compile and link an Ada program: This is a classic case of being unable to distinguish between a language and its implementation. For example, the Rational Ada environment makes such changes surprisingly fast, especially for large programs. Further, even with other Ada systems, the compile and linking time can be significantly reduced via such things as subunits. Regarding the observation that Ada is " a verbose hodgepodge formed by a committee who wanted it all but didn't know what all was available.": Any time I hear this kind of remark, I can be fairly certain that the originator is viewing Ada from a syntax-only perspective. Yes, if one has little or no formal software engineering education, Ada appears to be one of the most complex languages ever created. However, if one views the language as a vehicle for implementing modern software engineering, the language is very simple and straightforward. [For more of a software engineering perspective on Ada, you might wish to contact Dr. Charles McKay at the University of Houston , Clear Lake.] Finally, while many people contributed to the design of the language, it is primarily the work of one man: Jean Ichbiah (now at Alsys, S.A.). -- Ed Berard (301) 695 - 6960 -------