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.1 required=5.0 tests=BAYES_20,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8264dac98bc604d8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-16 11:05:52 PST Newsgroups: comp.lang.ada Path: sparky!uunet!widget!pole From: pole@evb.com (Tom Pole) Subject: Re: The actual quote from the Post AAS article Message-ID: <1993Mar16.175848.23975@evb.com> Organization: EVB Software Engineering, Inc. References: <1no3fbINN3h7@umbc4.umbc.edu> <1993Mar12.161548.6286@evb.com> <1993Mar12.231502.5522@sei.cmu.edu> Date: Tue, 16 Mar 1993 17:58:48 GMT Date: 1993-03-16T17:58:48+00:00 List-Id: A whole bunch of people said a whole bunch of stuff about the Washington Post article about the FAA project.... >>> >>>Any attempt to assert, based on the information in this article, that Ada >>>is the sole reason for failure, or even a major contributing factor, is >>>absurd. This project would have failed using any implementation >>>language. >>> >> >>The point is that these problems were known to be the major culprits >>in the "software crises" and Ada was supposed to solve them. >> >> Thomas >> > .... > >Tom, you seem to imply that Ada holds _some_ blame in the AAS problems, >since you point out that Ada was supposed to solve many of them. I would >appreciate it if you told us "netters" out here is you meant "solve" >to really mean "reduce", or if you actually meant to make some >unsupportable claim that Ada was supposed to genuinely solve the >software crisis. Okay, mea culpa. I tried to get away with a short reply, and now I'm paying for it. Blame Ada for the software crises ? or the AAS problems ? Absolutely not !! I meant "help solve", and be a major player in the solution. But go back and look at the discussions about why Ada was needed. The bureaucrats discussions that wrote the mandate, not the techie discussions. Although in some cases you can look at both. It was to be one of the tools that would help the DOD solve the software crises. Reuse was supposed to be there, and code generators, and AI, and a bunch of other keywords. I didn't make the claim that Ada would solve the software crises. I just heard it repeated, often. I was just amused that someone tried to distance Ada from the reasons why the project is in trouble, when Ada was supposed to be part of the solution. Ada is a worthwhile language, I enjoy using it in some cases (not all), and there are some projects I wouldn't work on unless they were using Ada. Not many, but some. > >In any case, this argument boils down to the issue of language choice. >Us "Ada Supporters" claim that any other language would have fared >just as badly (if not worse), precisely because NO OTHER language was >ever built to support systems on the scale Ada was. This is not to Well....., I think you should look at the switch software that AT&T uses. Its not written in Ada, and it is HUGHHHHHH !!!!!!!. Not designed with the 'large scale development support' requirements explicitly stated does not mean 'built to support'. 'C' does support large scale development. For that matter there are a lot of huge Cobol systems that have been running for years. Not efficiently, but still running. I'm not arguing the ability of controlling large projects using Ada. Just that other languages do support large scale development. >claim that one cannot build a large system in another language (say, C++), >but that doing so would require more resources. THAT was the bottom >line with Ada -- the software crisis was "more complex systems with >(possibly) fewer resources", and Ada was designed to tackle such problems. > Trained experienced developers and inexpensive proven SE tools are resources. In these categories Ada requires hard to find resources, and C requires easy to find resources. Sorry, but that makes a big difference. A lot of C++ folk think that Ada requires greater resources. Actually, I seem to remember that the big reason was to stop the standard DOD development cycle for embedded system development. GAther requirements -> write language to represent requirements -> build compiler for language -> write most of it in Assembly anyway -> Get on a new contract before the plane you delivered the present contract on crashes. :-) <<<---- NOTE SMILEY ! I can't believe that I'm here sounding like (NOTE 'sounding like') I support using C/C++ and (shudder !!) Cobol. I'm going to go write some Lisp, and read the rest of this thread tomorrow. >>> >>>-- >>>Mike Berman >>>University of Maryland, Baltimore County Fastrak Training, Inc. >>>berman@umbc.edu (301)924-0050 >> >> >>-- >> >>Thomas Pole > >dgw -- Thomas Pole