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.2 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,PDS_OTHER_BAD_TLD,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.lang.ada,comp.lang.c,sci.space,sci.space.shuttle Subject: Re: "C" vrs ADA Message-ID: <2260@cbmvax.UUCP> Date: Wed, 26-Aug-87 14:30:58 EDT Article-I.D.: cbmvax.2260 Posted: Wed Aug 26 14:30:58 1987 Date-Received: Fri, 28-Aug-87 06:50:15 EDT References: <36@sarin.UUCP> Distribution: na Organization: Commodore Technology, West Chester, PA Xref: mnetor comp.lang.ada:577 comp.lang.c:3935 sci.space:2704 sci.space.shuttle:284 List-Id: in article <36@sarin.UUCP>, eric@sarin.UUCP (Eric Beser sys admin) says: > Summary: not true ... not true > Xref: cbmvax comp.lang.ada:573 comp.lang.c:3880 sci.space:2640 sci.space.shuttle:278 > > Working in an industrial environment, and having used Ada, I do not see > how the "size" of a compiler matters in producing code that is efficient, > that is easily maintainable, and documentable. That's not what I said, and hopefully not what I implied. Once you learn the language, the size of the compiler has nothing at all to do with producing code that's easily maintainable and documentable, for certain. It may have something to do with the efficiency of the code, but that's more an implementation detail. They are certainly building compilers that code as efficiently as C for Ada these days. However, the size of a compiler does have everything to do with the correctness of the object code that the compiler will produce. Especially once you start adding in global optimizers and other items designed to produce much more efficient code. A larger compiler just has to be more complex than a smaller compiler, and thus it is more prone to containing errors that were not caught during validation. Because a complete validation test is very hard to design. Not impossible, but difficult. And you may not learn of the bug, especially in the case of languages used in Space and other hostile environs, until you hit a special case 100 million miles from Earth. > If you are used to C, you > may have trouble adjusting to the strong typing of the language. Ada is > a verbose language (if rich can be stated in any other words). But it is that > richness that makes the language so useful. What I mean by verbose is that it's wordy. Perhaps not as bad as M2 or Pascal, but it's wordy. Statement vs. Operation oriented. So while my C function appears as a whole in my Emacs window, my Ada function fills three screens. That's completely independent of richness. And as richness goes, C does pretty well as far as operator richness that Ada doesn't seem to consider necessary. All I'm saying is that that's what a C programmer will object to (I know this, I programmed in Pascal for 4 years). I use a C with ANSI prototyping; gives me the same level of type checking as I'd get in Ada or Pascal, same level of data abstraction available in Pascal. But I'm not forced into it. >> As for where it's used, mainly DOD I'd guess. It certainly isn't used much, >> if any, in commercial or industrial sectors. C's the language for most of >> these, though your Fortran experience could come in handy in some heavy >> duty scientific fields (most machines have Fortran compilers that code better >> than existing C compilers, but since there's more work being done on C, I >> wouldn't be surprised if this is changing). Forgot the Business sector's COBOL, and of course the prevalence of BASIC in the homes. I wonder who programs the most in what (ignoring whether they do it for fun or profit). I bet BASICs the closet to COBOL. Tells you that acceptance of a language rarely has anything to do with the language's overall quality; it's usually chosen for one or two reasons that don't always apply to the other things its used for. > I get irked when I hear this. This may have been true a year ago, but no > longer. Many customers (non DOD or NATO) are requesting Ada because of the > software engineering that it dictates. And many organizations forced to use Ada are getting around this by using C to Ada translators. Which I'm sure we both agree is a dumb idea, but they're still being used. And my point here is that I can engineer my software properly in C, even though it makes no attempt to force me to do so. And I can engineer my software poorly in Ada, even if it tries to make me do it correctly. > I am part of a large Ada project that is building a tool for use by our > engineers (industrial, commercial, as well as DOD contracts). After coding > this tool, we determined that some inefficiencies dictated a design change. > This design change proliferated itself through the entire system. The coding > for this change took about a man-month, but the debug and reintegration > phase took only two days. The system ran as before, must more efficient > due to the design change. Had the code been written in C, this would not > have happened. Many of the errors that were interjected by the engineers > were due to spelling, wrong variable selection, or unhandled boundary > conditions. These errors would not have come out during C compilation. Now who's talking about things that are no longer true. The Lattice Compiler I have on my Amiga, while by no means an up-to-date release, will very good type checking and would have caught most of these problems. Unfortunately PCC doesn't do this yet. > Eric Beser > EBESER@ADA20 - arpa > {mimsy}!aplcen!cp1!sarin!eric - usenet -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "God, I wish I was sailing again" -Jimmy Buffett, Dave Haynie