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 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: Socioeconomics, Ada, C++ Message-ID: <1991May18.194618.10112@netcom.COM> Date: 18 May 91 19:46:18 GMT References: <1991May18.022831.20653@grebyn.com> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: Ah, Ted's back. For those of you who missed it, a few months ago he posted some nonsense about Ada and, after I pressed him on it, he admitted that he actually knows NOTHING about Ada--he has no experience using it, he has never read a text on it, etc. His opinions are based entirely on hearsay and gossip. But that doesn't keep him from parading his ignorance in a worldwide forum. So now he's back... Anyway, I tend to ignore Ted Holden these days as a largely irrelevant annoyance. However, his posting gives me a chance to say a few things about Ada, C++, and the Ada mandate I've been wanting to say, so this time I won't ignore him: >Here's the rub. 40 Years ago or so, the government actually WAS in a >position top dictate terms to industry in areas such as programming >languages. Cobol flew because the industry was in its infancy, and >there were no better answers floating around out there in industry; the >banks and insurance companies bought off on it, and the rest is history. >Ada backers obviously think nothing has ever changed since then, whereas >in fact, a great deal has changed. Not only is government no longer >either the dominant player or in any position to dictate such terms, but >there are several FAR better answers out there in common usage, the most >obvious of which is C++. Well, first of all: when it comes to defense contracting, the DoD is by definition the dominant player, and is therefore in exactly the right position to dictate its terms. Bjarne Stroustrup once told me in a private conversation that he is opposed to the Ada mandate because he is opposed to anything that smacks of the "dead hand of officialdom". And yet, if Mr. Stroustrup or Mr. Holden hire painters to paint their house and specify that it be painted in light yellow exterior latex, is this the "dead hand of officialdom", or merely the perogative of the consumer? I wager that if the painters decided on their own that they didn't like the color light yellow or latex paint and decided instead to paint the house using lime green enamel they not only wouldn't get paid, they'd get sued. In the realm of defense contracting, the DoD is the consumer. The DoD is writing the checks and shelling out the money to get stuff built. Anybody who doesn't want to use Ada has the freedom not to bid on any of the DoD's contracts. But do, please, stop WHINING about it. As for Mr. Holden's claim that "there are several FAR better answers out there in common usage, the most obvious of which is C++", this betrays his brute ignorance concerning Ada I warned you about at the start of this post. When I pressed Mr. Holden as to the complexity of the projects on which he had worked, the answer was that he'd written some "routines" in C. As in, some little applications. The sorts of projects the DoD is concerned with are on the order of a couple hundred thousand lines on up. They involve teams of programmers, often distributed across multiple sites and companies, at various geographic locations. They involve millions upon millions of dollars, hundreds of thousands of staff-years, and multiple calendar years of effort. They are typically at the cutting edge of what is possible, and sometimes not even that--sometimes it is not even clear that the project CAN be accomplished, since there is no existence proof. For such projects, the claim that there are better languages to use than Ada is contradicted even by P.J. Plauger, the convener and general secretary of the ANSI C standards committee, who is on record having said "Above 100,000 lines of code, you probably should be writing in Ada". Ada was designed from the ground up to scale to such ambitious and complex efforts. This is certainly more than can be said for C (yes, large systems have been written in C, but this is more a testament to human willpower than to the software engineering capabilities of the language). Consider C++ for a moment. Mr. Holden appears to believe that this is some radical improvement in the state of language design, certainly far superior to Ada. Yet, as one who is familiar with both languages (as opposed to Mr. Holden), I see more similarities than differences between the two languages. Both have strong typing, separation of specification and imp- lementation, exceptions, and genericity, characteristics I refer to as "software engineering oriented". Once could probably engineer large complex systems in either language. But Ada is a far more mature language, with industrial strength tools proven on some of the largest projects ever attempted. And Ada is validated, which C++ is not (C++ isn't even a stable standard yet, but even once it is there's no reason to expect it to ever be validated). Of course, one would not expect someone who writes "routines" to understand the value of these things, despite the fact that I personally witnessed such issues prove the undoing of an ambitious C to C++ transition effort at a major U.S. corporation last year. >Reality dictates that DOD cannot afford to proceed with Ada any further >than it has. Aside from the multitude of unbelievable problems which >are involved with Ada itself, Note the cute rhetorical tactic: Mr. Holden raises the specter of Ada bogeymen but never actually commits to NAMING any of them. WHAT unbelievable problems? Last time I checked, Ada was being used quite successfully to engineer extremely complex systems for departments of defense throughout the world, NASA, the FAA, and many COMMERCIAL organizations in Europe and Japan. And Ada has not only been a smashing success on hard real-time embedded systems, but also in MIS and scientific application domains. >the real kicker is that we are about to >see the entire mainstream of American computer science using C++, This seems a rather strong statement to make, particularly considering the ferocity of some of the anti-C++ backlash on comp.object and in various OO journals, the continued strength of other OO languages including Eiffel and Smalltalk, and the simple fact that 70% of all software is written in COBOL and 15% of all software is written in FORTRAN, sectors far more likely to migrate to Ada than to C++. >DOD off in left field in a little toilet-bowl of its own making, paying >ten times the going rate and taking ten times the time for everything >they ever do; they'll get no help other than from small-potatoes >organizations such as Janus and/or Meridian etc. etc. And all of this >in an era of declining budgets. Hmmmm. Ada was originally conceived as a cost-cutting measure by the DoD because bitter experience proved that letting contractors choose their own language(s) led to an unbridled proliferation of languages and exponential increase in cost. The Ada mandate has brought this under control, and has been proven to reduce software development costs over the lifecycle, particularly when maintenance is taken into account. It seems to me that in an era of declining budgets, the forces motivating the use of Ada would tend to become STRONGER, not weaker: and this seems borne out by the fact that Congress recently made the Ada mandate the law, not just a convention. As for "small-potatoes" organizations, I guess Mr. Holden has never heard of IBM, DEC, Sun, Rational, or Borland, all of whom are quite actively pursuing Ada. But then, his unawareness of this is just more proof (if any was needed) of his staggering ignorance of the facts, and of his prejudicial attitude toward Ada. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ***************** * Proven solutions to software problems. Consulting and training in all aspects* * of software development. Management/process/methodology. Architecture/design/* * reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada. *