Ada vs C, objectivity requested

[Lucio de Re]

In article <1771 at awdprime.UUCP>, sanders at sanders.austin.ibm.com (Tony Sanders) writes:
> In article <8218 at hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu at hubcap.clemson.edu writes:
> >   So is a multi-alternative case, as provided by Ada:
> How do you do this in ADA?
>  
> ... silly code omitted ...
>  
> See how I left out the breaks on purpose.
>  
> In ADA you wouldn't be able to do this without duplicating either the
> case-expression (they aren't always simple numbers) or the statements.
>  
I don't think that's a serious drawback, unless you have a very
limited amount of memory. I like the facility that as you point out
does not exist in ADA, but I have got around the same lack in Pascal
and Modula 2 without any great identity crisis. And I have forgotten
the break on occasion, but I have learnt to spot the error quite
quickly, even though it is becoming more and more scarce in my code
(I generally enter all the case clauses, then separate them with
break's when using VI; in BRIEF, I would modify the macros to do this
for me).

It really is silly to knock a language on the basis of certain
constructs. Good programmers will use ADA or C successfully and bad
programmers will screw up in ADA or in C. We are not all or always
good programmers and we need to be alert to different possible
failings in the two languages. Can Bill Wolfe vouch for ADA having
no failings?

And, as justification for my satisfaction with C not putting too
many checks in my programming path, I have the following similitude:

I normally ride a motorcycle at speeds in excess both of speed
limits and of traffic speeds. I have to be very alert to survive, as
automobile drivers seem utterly oblivious of my presence. If I
travel more slowly, my attention span decreases and I become less
alert. Also, not being insured, I find I am more conscious of my
vulnerability than I was when I was insured.

Similarly, in C I try very hard to avoid its pitfalls. I follow this
thread because of the pitfalls that have been brought up (none that
I wasn't aware of, yet) and I regret my lack of ADA knowledge, at
least to some degree. In Modula 2 I too often let the compiler pick
up my distractions, which means that semantic errors are more likely
to have crept in. Is ADA similarly soporific; if so give me C, and
programmers under my supervision will program in Modula 2 because I
know the quality of the code I produce and I also know the type of
clever (read illegible, often wrong or at the very least incapable
of coping with special cases) code that less disciplined programmers
can produce in C. But it is an issue of survival. Bad C programmers
will eventually hang themselves, the same way that bad motorcycling
would have killed or crippled me long ago (and has killed and
crippled others) had I indulged in it. C requires self-discipline
where Modula 2 and ADA force discipline on you. The result is that C
programmers have more freedom, the price for which is one of greater
alertness or the possibility that the compiler won't pick up what
might be a simple mistake, while ADA and Modula 2 programmers have
to be devious to do what they may have to do that the language
inhibits.

And further, ADA suffers from a very bad disease: committeetis. By
the time a committee completes a definition, it cannot possibly have
included the latest developments in language design. Worse, once the
definition is finalised, implementation stretches further and the
language is (in at least some facets) obsolete by the time the
implementation is complete. To quote an example from the other side,
the ANSI standard for C has been superceded, prior to publication by
the availability of C++ compilers. Ironic? The standard has its
place, but it would be sad to stifle further development in C++ by
promulgating a standard that freezes it at this stage, for example.
We are learning so much, it is impossible to encompass all GOOD
language features in any one committee generated standard (thank
goodness!).

Take another point. The "0b" prefix Walter Bright added to provide
binary number representation is an obvious extension to C. The ANSI
committee did not consider it, nor did Stroustrup. Well, I like it
and I use it, and I would like it incorporated into the ANSI
standard. Certainly I would hate to lose it because some committee
states that its implementation invalidates my compiler's compliance
with the standard.

----------------------------------------------------------------------
I used to design nuclear reactors and you should see the code that
engineers and scientists come up with. Yuuuck! Spaghetti everywhere.
-------------------------------------------------- (Kenneth L Moore) -
Lucio de Re                        ...uunet!ddsw1!olsa99!proxima!lucio
-------------------------------------------------------- lucio at proxima
                Disclaimer: He must have been joking!