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, LOTS_OF_MONEY,MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:2905 comp.lang.c++:5524 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!ncrlnk!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: Ada Message-ID: <7053@hubcap.clemson.edu> Date: 15 Nov 89 16:06:41 GMT References: <14033@grebyn.com> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu List-Id: >From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden): > Journal articles indicate a continuing failure of Ada to work for embedded > systems as well as for large scale projects, a continuing failure to run > with acceptable performance on anything other than parallel or special- > purpose, expensive systems, and an actual gain in cross-system complexity > and decrease in the stated goal of reuseability. This is blatantly false; consider the November 1988 article in IEEE Software ("Large Ada projects show productivity gains"): After years of development and an initial skeptical reception, many people are now using Ada and saying that they like it... The growth in Ada's use has been helped by favorable reports from early adopters ("Ada Catches on in the Commercial Market, Soft News, IEEE Software, November 1986, p. 81) and by the growing number of validated compilers... project results show that Ada can greatly increase productivity for large systems... [in a 1.2-million-line Ada project] reuseable software developed on the project was counted only once. Roughly 13 percent of the delivered software was reuseable. This reuse saved 190 man-months of effort (a 9-percent savings) and reduced the schedule by two calender months (a 4-percent savings)... Productivity for the execution environment -- including the operating system, data management, information management, communications support, and communications interface -- was 550 lines per man-month... Productivity for the applications software... was 704 lines per man-month... the average productivity of the 1,500 systems in productivity consultant Lawrence Putnam's database: 77 lines per man-month (at the 1.2-million-line level)... Sounds like a continuing *success* to me... > In particular, the > ordinary systems which most people will be seeing in front of them for the > next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably. Precisely the point of Dr. Charles McKay, head of the Software Engineering Research Consortium, in his Tri-Ada '88 presentation, "Standards for the Sake of Standards -- A Recipe for Failure". A prime example is Unix; the current POSIX effort aims to standardize 1960's technology, thus resulting in a "lowest common denominator" which locks users into obsolescence. Ada's problem with Unix is that Unix, being 1960's technology, does not properly support lightweight processes. Modernized versions of Unix (e.g., MACH) which are designed to provide such support remove the difficulty. Note that C or C++ programs making use of the same "heavyweight" tasking facility will be equally slow, since they rely on precisely the same system. If one does not have to struggle with the limitations of *Unix*, then there is a wide selection of Ada compilers which run Ada within that environment quite nicely. Some, like the Telesoft TeleGen2 compiler, have global optimization facilities which result in better code than that which can be produced by current C compilers (as of Tri-Ada '88). > C began with real machines, real programmers. The idea seems to have > been: [...] end up with a kind of high-structured, low-level language; > a thinking-man's assembler. Yes, as one Usenetter's .signature states, "C combines the power of assembly language with the flexibility of assembly language". Fortunately, the economics of software development are in favor of using considerably higher-level languages. > C++ appears to BE the very language which Ada was supposed to be > (the spirit of the law) but never can and never will be. Total rubbish; C++ retains all the low-level and dangerous facilities of C, which is obsolescent by modern software engineering standards. As stated by Fairley (Software Engineering Concepts, page 228), Modern programming languages provide a variety of features to support development and maintenance of software products. These features include strong type checking, separate compilation, user-defined data types, data encapsulation, data abstraction, generics, flexible scope rules, user-defined exception handling, and concurrency mechanisms. This chapter discusses these concepts... Now C++ has one useful feature which Ada does not: inheritance. But it is also (as its designer freely admits) lacking in generics and exception handling, and also does not provide a means of expressing concurrency in a standardized, portable way. Since tools such as Classic Ada permit the use of inheritance with Ada (generating *standardized*, compile-it-anywhere code), this is something which can be worked around until Ada 9X brings it in directly. > Ada is what you might expect from a programming language designed by > committee; it is unbelievably slow, an unbelievable resource hog, This has been a property of some early Ada *compilers*, but is not a property of the Ada *language*. Fortunately, compiler technology is now capable of delivering tight, efficient Ada object code, better than that being produced by C compilers. Compilation is slower because the Ada compiler is doing much more work for you; this reflects again the economics of software development in that machine time is cheaper than programmer time. > [...] There is the August 21 89 issue of Government Computer News > describing the problems which the huge FAA Advanced Automation System is > having due to IBM Ada implementations and tools (or lack thereof). Are you saying that this is the fault of the *language*, or of IBM? > There is no real way to call [Ada] from a Cobol program. Ada users can call COBOL or any other language using pragma INTERFACE; COBOL needs to have a similar standardized means of calling other languages. Given that it does not, ad hoc means of calling other languages have been devised; there is no reason why such techniques cannot be used to call Ada just as well as C or any other language. But this is COBOL's problem, not Ada's. > the programming style being promulgated by DOD for Ada [descriptive > variable names] is anti-conducive to the stated goal of readability; To C hackers, who are accustomed to single-letter variables, yes. Software engineering specialists tend to have the opposite perspective. > Second, DOD is often insisting on portability via Ada rather than > portability via UNIX, POSIX calls etc. This amounts to such things as > insisting, for instance, that vendors provide direct Ada hooks to a > database rather than simply writing an Ada -> C -> database hook. Typical > vendor response is either "F... You" or "Manana". And the response of the Ada community is to turn to companies such as The Ada Ace Group, Inc., a technical consulting company specializing in the development of Ada interface to software products and applications. They provide customized pure Ada interfaces to existing commercial software products, such as databases, operating systems, and specific applications such as X-Windows. (Contact information: 4254 Indigo Drive, San Jose, CA 95136; (408) 267-8296) Do you really think the Ada community, with its emphasis on standardization and vendor independence, is going to be stopped by an intransigent vendor? > A military project involving Sun machines and Ada was abandoned after > something like 4 years and $30 million effort because of unacceptable > performance; database screens were taking over a minute to come up. The > design work had all been done according to your formula, the individual > modules had been designed, written, and tested, all according to the > standard military schedules and formulas (2167 etc.). Everything seemed > hunky dory, only when they put the fricking thing together, it was too > damned slow to use. And, the remarkable thing is, the very system the > military insists upon for management of software contracts prevented > anybody from knowing they were in trouble until four years and millions > had been blown. The government people involved were essentially reduced > to the role of actors in a Greek tragedy. > > Asked for a solution, my firm weighed the choice between offering an Ada- > to-C converter and silence, and opted for silence. How about applying a profiler and recoding the "hot spots"? If the slowness of Unix process handling is a problem, then a more modern version of Unix should be used. Your company should have considered more than two options. There are problems in the government management process, but this pertains to the government and not to Ada. Bill Wolfe, wtwolfe@hubcap.clemson.edu