Re: "C" vrs ADA

[jesup@steinmetz.steinmetz.UUCP (Randell Jesup)]

[ To give my comments perspective, I have been programming in ADA ]
[ professionally, in a government DARPA project.		  ]

In article <36@sarin.UUCP> eric@sarin.UUCP (Eric Beser sys admin) writes:
>In article <2231@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
>
>> The biggest problems with Ada is the massive size of its compiler and the
>> verbosity of it's language.  I guess if you really like Pascal or Modula2,
>> you might adjust, but if you're used to C, it might take some getting used
>> to.  
>
>   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. 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.

	The size of the compiler DOES matter, even in an industrial 
envirionment.  The Vax Ada compiler, supposedly the best out there (according
to a well-informed source on the original panel/whatever), is one of the
things that forced us to quadruple our machines memory.  It was not the
only thing, but it was so bad we were doing batch compiles at night!
(Shades of the early 70's!)  Otherwise, we'd get 500 page faults/cpu sec.
	Concerning the efficiency of the generated code, our absract data
types and the operations on them took well over 1/2 meg, not including the
program that would use them.  By comparison, the initial quick-hacked C
version done for the phase 1 final review (in 12 man-weeks!) was about
300-400K (with a fair amount of duplicate code, like parsers in a number of
modules).  This is obviously not a very scientific comparision, but it does
show something (at least that it caused much more disk use).

>> 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).  Ada is certainly general purpose
>> enough to be used elsewhere if you have access to a compiler for it, and it
>> generally has alot of things built into it that you have to add to C language
>> (like tasks, exceptions, etc.).
>
>  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. Ada is not just a computer language,
>it is a software engineering methodology. Many customers who originally
>requested C are now asking for Ada. The compilers today are becoming efficient.
>There are some imperfections however, and all is not rosy. But there are
>compilers for the 68020 that produce well optimized code. There are compilers
>for the 1750A military processor that produced adequate code, although 
>not as well optimized. Toolsets are now usable. In fact, you can buy a 
>validate Ada compiler for the IBM PC-XT (Meridian) that does not require
>extra memory, is somewhat expensive (700.00), but not the $3000.00 that
>the leading pc vendor charges.

	But how compact are the programs produced by it? And how fast?

>Let me give an example from actual experience.
>
>  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.

	Partially true.  Any person who does not use lint on all code in
a large (or even small) project deserves what they get.  Lint catches many
things, though not as many as Ada.  If the system has been designed using
good methodology, it should be fairly easy to ripple changes through
whether it's in Ada or C.  Also, many errors I have seen in Ada programs
are also subtle, and often due to the immensity of the language, and the
trouble figuring out how it should behave when using various constructs
together.  (See many of the past messages here for examples).

>They would have manifested themselves in various (or nefarious) bugs. These
>interjected errors were found (80% approx) during compilation of the code.
>An additional 15% were found on first startup of the system by constraint
>and unhandled exceptions. The remainder were found on integration.

	The thing that causes the most errors that I have seen are Ada
compilers that don't warn you when you access an unitialized variable, therefor
causing random failures (the worst kind!)  Even my micro-computer C compiler
warns me of these (without even running lint.)  In fact, I saw people try to
figure out whether integers (and variables in general) were initialized
for several hours (I HATE the LRM!)
	If the government is concerned with reliability of software, they'd
better get some compilers that can find this, or it's all been for naught.
(I know it's easy, is there something in the language spec that says not
to warn the user?!)

>My suggestion is that you learn software engineering, object oriented
>design, and the use of software tools. Then learn Ada. You will find
>that the C will come in handy when you have to try to understand what
>some engineer did so to do an Ada redesign.

	Ditto about learning good design.  C is useful in many other situations
where Ada is not, and vice versa.

	I believe that for each problem (and set of contraints, such as time/
resources/etc), there is a most appropriate language, from FORTRAN to Ada to
C to Cobol (Yuch!) to assembler to Prolog to Lisp (etc).  The worst code 
you'll see is when someone tries to fit a XXXX language slipper (solution)
on a YYYY language foot (problem).  It may very well be that for the major
class of problems the DOD has that Ada is an appropriate solution.  But
certainly not for all problems the DOD has, and absolutely not for all 
problems anywhere.

>Eric Beser
>EBESER@ADA20   - arpa
>{mimsy}!aplcen!cp1!sarin!eric - usenet

	Randell Jesup
	jesup@steinmetz.UUCP
	jesup@ge-crd.arpa