Re: Software vendors not using Ada but C

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa s.edu!swrinde!network.ucsd.edu!munnari.oz.au!goanna!ok@ucbvax.Berkeley.EDU (Ri chard A. O'Keefe)]

In article <9306180819.aa14968@dsc.blm.gov>, cjames@DSC.BLM.GOV (Colin James 06
21) writes:
> Ted Holden writes that "Programs written in geneic C port, from just about
> anything to just about anything else".
>   
> This argument is mistaken as anyone knows who has worked on a larger C
> project of greater than 10,000 lines of code.

Too true.

> Consider the generic C statement:  c=a+++b;  .
> 
> This ambiguous statement can mean four things which are all equally 
> admissible as ANSI C:

This is outrageously false.  The ISO standard, section 6, subsection Semantics,
paragraph 2, and example 2 make it crystal clear that there is precisely one
way of dividing this into tokens:
	{c} {=} {a} {++} {+} {b} {;}
The grammar admits only one parse, and that parse admits only the
interpretation
> 3.  c = a + b ;  a = a + 1 ;
(If c and a are aliases, the construct is explicitly undefined.)

> Note that Appendix F of the the ANSI C standard suggests that in cases 
> where language syntax is ambiguous, the use of spaces can alleviate
> confusion.  But who ever heard of an ANSI language which relies on 
> spaces to que the compiler.  

That's "cue", not "que".  I don't know what appendix F of the ANSI
standard might have said, but I can find nothing similar in appendix F
of ISO 9899:1990, and in any cases the appendices are informative, not
normative.  As for spaces having lexical effect, a great many ANSI
languages do that, including Ada.  Consider
	x := x -- 1;
Here -- begins a comment.
	x := x - - 1;
Here the division into tokens is very different.  (The result happens to
be illegal _syntax_, but the space has made a lexical difference which is
_precisely_ analogous to the C case.)

> Also, Mr Holden's argument fails with floating point math for this reason.
> Two ANSI C compilers on the same hardware platform can produce different
> numerical results because the math stuff in C is done at runtime and it
> is not required to be implemented according to any standards.  This is
> why banks and financial institutions have been burned when herded to C.

Be fair.  It is entirely possible for two Ada compilers on the same
hardware platform to produce different numerical results.  (The "two"
compilers might well be the same compiler with different optimisation
levels.)  It is also possible for two Fortran compilers on the same
hardware platform to produce different numerical results.  It isn't even
rare.  ISO C provides more information about floating-point types (via
<float.h>) than Fortran 77 did, which didn't stop Fortran 77 being very
useful for numerical work.

Banks and financial institutions have been burned using COBOL, Fortran,
PL/I, Pascal, RPG, CICS, you name it.  Why should C be any different?
_Have_ any banks been "herded" to C?  Our financial masters are the
500-pound gorillas of the concrete jungle, they go where they want.
(I suspect _my_ bank of using an abacus.)

> If C is portable as Mr Holden suggests, then why is it that C ports from
> one platform to another take so long.

In practice, the answer is very simple, and has little to do with the
language used:  the original code wasn't written to be portable.  There is
one method that I know of for developing portable code, and that is to
develop it on several different machines at the same time.  Anyone who wants
to develop non-portable Ada code can do it, no trouble.

Look, I agree that Ada is a far better language than C.  (Which is why I
_grabbed_ Ada/Ed for the Mac as soon as I heard about it.)  But arguments
against C would be so much more convincing if they were _correct_.