Re: Software vendors not using Ada but C

Re: Software vendors not using Ada but C

[Colin James 0621]

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

If C is portable as Mr Holden suggests, then why is it that C ports from
one platform to another take so long.  For example when Oracle ported from
the DEC VAX to the IBM PC it took longer than six hours, six days, six,
weeks, and six months.  Another example is Windows NT Beta which supposedly
has four million lines of code and is by most accounts still at a pre-
release alpha level which the eager public is willing to pay for to debug.
  

Re: Software vendors not using Ada but C

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa]

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

Re: Software vendors not using Ada but C

[Mike King]

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

Re: Software vendors not using Ada but C

[agate!howland.reston.ans.net!math.ohio-state.edu!sdd.hp.com!col.hp.com!cs]

In article <20366@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard  
A. O'Keefe) writes:
>
> > 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.)
>

The original claim startled me into action.  I tested this on 3
compilers, 2 for DOS and gcc on Unix.  All three got the same
results and they matched option 3, that is a + b; a = a + 1;

I personally hate  C and want all the ammunition against it I can
get but false claims such as this don't help.

-- 

Bob Love                            	rlove@raptor.rmnug  (NeXT Mail OK)
					BIX: rlove
--------------------------------------------------------------------------

Re: Software vendors not using Ada but C

[Bill Yow]

In article <9306221230.AA05804@sed00.sed>, mking@FSD.COM (Mike King) writes:
|> In INFO-ADA Digest, V93, #387,  Colin James 0621 <cjames@dsc.blm.gov> writes
:

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

Well, when I was in school the C class I took (in 86) the professor would not
allow us to use ().  The reason, he felt that a good C programmer should not
need to use () but should know all of the precedence rules.  In fact he would
take off points on test for the use of ().  So there are at least 30 C programm
ers
who had it drilled into there heads not to use ().  

And this was not a small school either, the engineer school had over 5,000 stud
ents and the entire school was over 20,000.

                                                Later,
                                                Bill Yow
                                                (713) 280-1591
                                                yow@pat.mdc.com
                                                byow@mcimail.com

My opinions are my own!


 

Re: Software vendors not using Ada but C

[Robert Firth]

In article <1993Jun23.190753.8583@aio.jsc.nasa.gov> yow@pat.mdc.com (Bill Yow) 
writes:

>Well, when I was in school the C class I took (in 86) the professor would not
>allow us to use ().  The reason, he felt that a good C programmer should not
>need to use () but should know all of the precedence rules.

Good grief.  And I thought Jean Ichbiah was paranoid when he refused to
give "and" and "or" the same precedence rules in Ada that they had in the
propositional calculus.  Not verbatim, but approximately: "Robert, a
programmer should never have to learn a new precedence rule as part of
a language.  The language should use only rules everyone already knows."

As usual, Jean, you were right.

Re: Software vendors not using Ada but C

[cis.ohio-state.edu!math.ohio-state.edu!uwm.edu!ogicse!netnews.nwnet.net!n]

In article <1993Jun23.190753.8583@aio.jsc.nasa.gov> yow@pat.mdc.com (Bill Yow) 
writes:
>In article <9306221230.AA05804@sed00.sed>, mking@FSD.COM (Mike King) writes:

[stuff related to c=a+++b;]

>Well, when I was in school the C class I took (in 86) the professor would not
>allow us to use ().  The reason, he felt that a good C programmer should not
>need to use () but should know all of the precedence rules.  In fact he would
>take off points on test for the use of ().  So there are at least 30 C
>programmers who had it drilled into there heads not to use ().  
>
>And this was not a small school either, the engineer school had over 5,000
>students and the entire school was over 20,000.

If you say so, but it seems highly unlikely that anyone would take the
parenthesis-minimization aesthetic to such extremes as to claim that

    c=a+++b;

is a good thing to write.

I could believe that your professor frowned on such things as

    result=(condition1||(condition2||(condition3||condition4)));

because in cases like this, the parenthesis are nothing but noise
and ruin an otherwise clear and readable statement.

And even in cases like

    result=((condition5&&condition6)||(condition7&&condition8));

or

    result=((integer1*integer2)+(integer3*integer4));

I would argue that the parenthesis render the expression *less*
readable, and that (IMHO) everyone ought to know which of && and ||
or * and + (see, no parens needed for that to make sense, right?)
has the higher precedence.  Of course, logical use of whitespace
can be very helpful, so I might write

    result = condition5&&condition6 || condition7&&condition8 ;

or

    result = integer1*integer2 + integer3*integer4 ;

I don't claim that everyone has to think my way about this, but I
can certainly see why a professor would want to discourage the use
of extraneous parenthesis in cases like these.

Furthermore, forbidding the use of () might temporarily (with
appropriate explanation and with "debriefing" afterwards) serve as
a good exercise in learning the precedence rules.

Anyone who would argue against parens in

    c=a+++b;

is a fool, though.  Are you *sure* your professor was *this*
dogmatic about it?


--ben
(Yes, I know this has nothing to do with Ada)

Re: Software vendors not using Ada but C

[Michael Feldman]

In article <1993Jun23.163346.29745@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth
) writes:
>In article <1993Jun23.190753.8583@aio.jsc.nasa.gov> yow@pat.mdc.com (Bill Yow)
 writes:
>
>>Well, when I was in school the C class I took (in 86) the professor would not
>>allow us to use ().  The reason, he felt that a good C programmer should not
>>need to use () but should know all of the precedence rules.
>
>Good grief.  And I thought Jean Ichbiah was paranoid when he refused to
>give "and" and "or" the same precedence rules in Ada that they had in the
>propositional calculus.  Not verbatim, but approximately: "Robert, a
>programmer should never have to learn a new precedence rule as part of
>a language.  The language should use only rules everyone already knows."
>
>As usual, Jean, you were right.

And how! Students have more important things to learn than big precedence
tables. IMHO the precedence rules are designed to make expression
evaluation well-defined and (reasonably) intuitive, in the absence of
parentheses. I teach precedence as a more-or-less advanced topic, more
to illustrate how the language designers thought out the precedence
than to make the students learn it.

The old reason for omitting parentheses was to save keystrokes, in the
punchcard days when your department was charged, by the keystroke, for
keypunch services. I guess the new reason is to show how macho you are.
I pity your teacher's students - they were forced to spend so much effort
on diddly stuff that undoubtedly they neglected the more important overall
structural and design issues.

This has nothing and everything to do with Ada. A program is written once,
but read a million times. Readability is, of course, a matter of taste,
but readability should be an important, if not _the_ important, criteria
in code layout (including parentheses).

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-5296 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is what those other guys get from the Government."
------------------------------------------------------------------------

Re: Software vendors not using Ada but C

[ghost.dsi.unimi.it!univ-lyon1.fr!scsing.switch.ch!epflnews!disuns2.epfl.c]

In article <20afbsINN6or@news.u.washington.edu>, bketcham@stein2.u.washington.e
du (Benjamin Ketcham) writes:
:
: Of course, logical use of whitespace can be very helpful, so I might
: write
: 
:     result = condition5&&condition6 || condition7&&condition8 ;

Surely you mean

	result = cond5 && cond6||cond7 && cond8 ;    :-?


Relying on whitespace to convey operator precedence is double-plus
ungood.  You cannot hope that every programmer or mathematician and
non-programmer or non-mathematician (wait, can you parse it? should
that rather be and and and or or or or?  or comma comma or?) in the
world should assign universal precedence levels to and and or
(parenthesis omitted, since precedence levels are self-evident :-).

Thou shalt use parenthesis.
-- 
Magnus Kempe			"Reason ... is the glory of our nature."
Magnus.Kempe @ di.epfl.ch				-- Elihu Palmer

Re: Software vendors not using Ada but C

[Mark Bayern]

>
>Relying on whitespace to convey operator precedence is double-plus
>ungood.  You cannot hope that every programmer or mathematician and


Did you mean to type "++ungood"  ??

Re: Software vendors not using Ada but C

[David Weller]

In article <146@mlb.win.net> mbayern@mlb.win.net (Mark Bayern) writes:
>>
>>Relying on whitespace to convey operator precedence is double-plus
>>ungood.  You cannot hope that every programmer or mathematician and
>
>
>Did you mean to type "++ungood"  ??
>
No, I'm certain he meant "ungood++"  :-)

-- 
-Comments above aren't neceessarily the opinion of the SEI, AJPO, or CAE-Link-
David Weller  |  Have you hugged your DRAGOON lately?
----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----