Re: "C" vrs ADA

[gwyn@brl-smoke.ARPA (Doug Gwyn )]

In article <36@sarin.UUCP> eric@sarin.UUCP (Eric Beser sys admin) writes:
>I get irked when I hear this. This may have been true a year ago, but no
>longer...
>Ada is not just a computer language,
>it is a software engineering methodology.

It does amount to that.  It also gives one little choice about
the matter; it's designed to enforce one particular methodology.
If one has different ideas (as many workers in software engineering
do), then it becomes a battle against Ada's built-in model.

>... 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.

"I get irked when I hear this. This may have been true a year ago,
but no longer..."  Actually it need never have been true.  Read on.

>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.
>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 language the code is written in is really a very small part of
structured software methodology; one can apply the techniques in
COBOL, PL/I, FORTRAN, Pascal, or C.  As a matter of fact, there are
C environments for sale that are just about as "safe" as Ada; most
typo and similar errors are caught by C compilation and "lint";
unhandled exceptions in C typically produce an immediate core image
for debugging, etc.  Very little difference, really.

>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.

Ada is worth learning, simply because it will see widespread use.
Structured software development methodology is also worth learning
(Yourdon recommended).  The two are not synonymous.  Nor are C
programming and random hacking.  You probably don't see much of
the really well-implemented systems programmed in C, not because
they don't exist, but because they are likely to be proprietary.
The "freeware" you see on the net is not typically the product of
informed software engineering, but just someone's quick solution
to an isolated problem they ran into.  Don't judge the language's
capabilities based on that sort of evidence.

C's one really major problem from the structured viewpoint is
that it has only two effective levels of name space, module
internal and global.  This makes it necessary to strictly
allocate global names, which is an annoying but solvable problem.