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=1.6 required=5.0 tests=BAYES_00,INVALID_DATE, LOTS_OF_MONEY,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!aplcen!haven!grebyn!ted From: ted@grebyn.com (Ted Holden) Newsgroups: comp.lang.ada Subject: Re: A farewell to Ada Keywords: Ada users repent; the end is near... Message-ID: <14036@grebyn.com> Date: 19 Nov 89 03:33:23 GMT Organization: Grebyn Timesharing, Vienna, VA List-Id: Lots of good replies.... From: Richard S D'Ippolito, Software Engineering Institute, Pittsburgh, PA >> Does Ada work any better for large scale systems? Another article >>in the same Journal of Electronics Defense issue describing use of Ada on >>the 1,246,000 line Army AFATDS system claims that: >> >> "Ninety percent of the software requirements were met with no major >> software problems." >> >>as if this were good. The man is claiming that he had major language- >>related problems with 124,600 lines of code out of 1,246,000. >how can you expect to be taken seriously? Do you really believe the math >and premises behind your statement? Wow! The journal should be in your library or in that of Carnegie Mellon. I'm sure as hell not making any of this stuff up. Get serious. I'm quoting one of your own journals which was necessarily written in such a way as to paint Ada in as FAVORABLE a light as possible, and the most favorable thing the one gentleman could say was that he ONLY had major problems with 10% of his code. Pretty sad. From: Bill Wolf, Clemson >>>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... Sounds very subjective to me and it sounds like a lot of factors are being left out. The funny thing is, that this subjective argument concerning productivity is the only technical or quasi-technical argument I have ever heard in favor of Ada. Every other argument in favor of Ada which I have ever heard was a variant of: "We will cut your ____ie off if you do not use Ada on your project..." That's not much to have to say to the world. >> 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. Proprietary OSs lock users into obsolescence; UNIX frees them. Until Dr. McKay publishes HIS portable OS and large numbers of people begin using it, UNIX will remain the only answer. > 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). I have personally watched the Telesoft Telegen Ada compiler take over 20 minutes to compile a 35 line program into a 300 KB executable on a 68020 based machine with almost nothing else happening on it. Knowing the Ada community's idea of progress, I'd expect the Telegen2 to take about 15 minutes to do the same job. Mach is five years away from anything approaching large scale use in America; right now, it is a student's hobbyshop project, albeit a hell of an interesting one. Mach-like or Mach-derived products such as the Sequent OS are beginning to be seen and, if your name is John Rockafeller, you should have no difficulty coming up with such a system to run Ada on. Ada does, in fact, run accepteably on a Sequent. Remember, however, the difficulties of building semetric parallellism into an imbedded system; that aileron controller won't be a Sequent. Remember also that the primary customer for Ada is supposed to be the U.S. military. Do you have any idea what the state of the art for computer hardware is in the U.S. military? We're talking about Unisys/Arrete 5000/80's, 5000/90's, 8186-based devices running Zenix on top of BTOS..... The 5000/95's are just now being installed. Get the idea? As for struggling with the "limitations" of UNIX, you'd better either get used to it or move to Mars. There is no other easily portable, mature operating system. Without it, you'll always be using ten-year-old hardware, because developing an OS the old way (like IBM and Microsoft seem intent on doing with BS/2) takes ten years. They paint themselves into some funny corners with it, like trying to tell the world that the N-10 chip is actually a graphics coprocessor for the 486. That's like having Theodore Roosavelt serve as Jimmy Carter's secretary of agriculture; it's driven by the obvious accessment of the chances of running BS/2 on an N-10, which is about like the chance of hell freezing over tommorrow morning. >> 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. > Fortunately, the economics of software development are in favor > of using considerably higher-level languages. Then perhaps you could explain the total dominance of C in the mini/micro world, the only completely healthy segment of the computer market? The last figures I've read indicated that 65 percent of all software development in this world was being done in C, and the next highest figure for any other language was around six percent. Are Borland, MicroSoft, Lotus, Ashton-Tate, WordPerfect, and all of those companies just that stupid? >> 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 Those features are there because they are necessary for real world programming. Tacking those features onto or into an Ada program (which is meant for real-world use) is not a superior solution; it makes for non-portable code. >> 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. Dead wrong. This is a grey area, but Ada tasking basically requires that the starting point be an Ada program i.e. predictable results/full Ada functionality are not possible from an Ada module called from a routine written in another language. The requirements to link low-level kinds of routines into Cobol programs are very real. Every Ada manual I've seen says that results from such code are unpredictable. >> 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"? There weren't any "cold" 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. First, the problem with performance didn't involve UNIX. Second, to my knowledge, the vender only offers the one version for the machine. Again, the customer was not John Rockafeller. >> [...] 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). > Apparently IBM has now changed its tune; its recent brochure > entitled "Ada and IBM... Capability and Committment" states: > IBM is committed to Ada. Ada's support for modern software > engineering concepts, its breadth of application, and its > support for reuseable software components place it squarely > in the forefront as a language of choice for both IBM's > software engineers and for IBM's customers. IBM was and is committed to PL/1, the PC-Jr, OS/2, MCA... Apparently, they have simply added Ada to their list of big-time losers with which (temporarily) there is a profit to be made. From: CAROZZONI: The Internet >>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 acceptably. > And the technical reason is ? Inferior design of the programming language. > Standardization among C compilers can best be shown by the Billions > and Billions of "ifndef"'s and "ifdef"'s in any C program such as > the Emacs Editor source code. You actually USE Emacs? Did it come bundled with Ada? Does the Internet have any kind of a rule regarding picking three losers, like the old New York three-time-loser law? How about Emacs, Ada, and Oracle? >>.....PC and lots of memory to play with, Ada compilers at least will get >>back to you on the same DAY; ................................... > I use Ada on a PC/AT (as do others here) and also use MS C 5.1! > We can't agree with you on this. Try reading the Ada compiler > installation manual. The best compile times I've ever heard of either on a VAX class machine or a 386 is around 1000/2000 lines/minute; Turbo C is around 15000 on a fast 286, Zortech C++ about the same, Turbo Pascal around 40000 on a fast 286; God knows what they run at on a 386. We're talking about at least a two-order-of-magnitude differential. >>......After All". Remember, Ada has been around since 1979. If that were >>the best anybody could say about C after ten years, C compiler salesmen would >>be starving and dying like flies. > Your facts are consistently confused. The availability of validated Ada > compilers covering a reasonable selection of machines have only > been around for 4-5 years. Ada started in 79; taking 6 years to write a validated compiler doesn't speak favorably of your efforts. World War II was fought in less time. >>.................... "Ada and UNIX doesn't work". I've heard that a >>million times from users, first time that succinctly in print. Between >>UNIX and Ada, UNIX is the real-world standard.................. > The UNIX standard? (BDS, System 5, Xenix, OSF, UI, Mach etc)? Pick one. >> Ada threatens to leave DoD stranded and technologically backwards; >>out of the mainstream of American computer science.............. > A recent article indicated that Ada and Ada like (Pascal, Modula 2) > languages are the primary choice for Software Engineering Curriculums. > May be you should enroll in one. Sorry, I live in the real world; I can't afford the brain damage that might do. .................... Am I missing something by citing 1988 and 1987 journals? Is it possible that in the year since the articles I have mentioned were printed that Ada has come of age? Consider the article concerning the Rational machine in this week's (Nov 13 89) issue of Government Computer News, page 47. It claims the price of the latest Rational Ada development machine has "come down" to around $100,000. It also claims that the machine will be used as a network resource in conjunction with Sun, DEC, and IBM file servers. The obvious implication is that these other machines, which are quite powerful, yet lack the capability for serious Ada development. Why is that? IBM, DEC, and Sun computers can easily be used to develope software in C, Fortran, Pascal, C++, Cobol... My own most recent machine is a Primus 386 which runs at 25 mh with no wait states, has 4 meg main memory and a 104 mh Conner disk which I paid around $2300 for. This system could easily be used to develope almost any kind of software with any reasonable language. What are you people getting for the other $97,700 with the Rational? Consider the possibility of an analogy from the world of medicine. In the medical world, the Rational might be referred to as a "heroic measure", possibly an iron lung. The patient (in this case, Ada), would be referred to either as "a terminally ill patient" or "the deceased". Aside from myself, who is saying that the end is near for Ada? Possibly, a certain Mr. Gorbachov in the CCCP, who is basically declaring the cold war to be over, and a Mr. Cheney in Washington D.C. who is talking about cutting 180 Billion from the U.S. defense budget over the next five years (Wash. Post, A1, Nov 18, 89). Anybody care to bet that Ada doesn't become one of the first casualties of all this? Ted Holden HTE