Re: "C" vrs ADA

[daveh@cbmvax.UUCP (Dave Haynie)]

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