From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: Tue, 22 Jun 93 08:30:30 EDT
From: mking@fsd.com (Mike King)
Subject: Re:  Software vendors not using Ada but C
Message-ID: <9306221230.AA05804@sed00.sed>
List-Id: <comp.lang.ada>

In INFO-ADA Digest, V93, #387,  Colin James 0621 <cjames@dsc.blm.gov> 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.
> 
> Consider the generic C statement:  c=a+++b;  .
> 
> This ambiguous statement can mean four things which are all equally 
> admissible as ANSI C:
>   
> 1.  a = a + 1 ;  c = a + b ;
> 2.  b = b + 1 ;  c = a + b ;
> 3.  c = a + b ;  a = a + 1 ;
> 4.  c = a + b ;  b = b + 1 ;
>   
> 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.  

Have the postfix and prefix operators changed meaning?  I learned "x++" means
"reference x, then increment it," while "++x" means "increment x, then 
reference it."  Therefore, ambiguity in the generic C statement ` c=a+++b; '
should either be:

1.  c = a + b; a = a + 1;     [c = (a++) + b]   or
2.  b = b + 1; c = a + b;     [c = a + (++b)]

However, the real problem is the fact the statement doesn't convey the
intention to the reader/future code maintainer.  Only a poor software
engineer would write a statement like `c=a+++b;' in his/her code; the
rest of us would write `c=(a++)+b;' or `c=a+(++b);' so as not to depend
on the order of evaluation, and more importantly, to inform future
generations what was intended by the statement.

OTOH, I've maintained and ported Ada code that is just as
uncommunicative.  The only difference is the Ada code made a subroutine
call instead of using a built-in operator.  The code in question did
not have any commentary to tell the reader what was being done (why the
subroutine was called, what it did to the parameters, what it returned,
etc.).

I've also heard too many people say that "Ada is self documenting."  Bull snot.
Written by a poor software engineer, Ada can be as convoluted, twisted, and
confusing as Latin, and in the hands of a good software engineer, C can be
a work of art.


> Mike <

-------------------------------------------------------------------------------
Mike King           |  +1 301-428-5384            |  I don't speak for my
Software Sourcerer  |  mking@fsd.com or           |  employer.  My employer
Fairchild Space     |  73710.1430@compuserve.com  |  doesn't speak for me.
-------------------------------------------------------------------------------

A gleekzorp without a tornpee is like a quop without a fertsneet (sort
of).