Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[J. Giles]

In article <1992Dec8.072300.21473@smds.com>, rh@smds.com (Richard Harter) write
s:

|> [...]                                          The FORTRAN bug which
|> >resulted in the destruction of the first Venus probe was that in:
|> >
|> >     DO 20 I = 1,10
|> > 
|> >the comma was replaced by a period:
|> >
|> >    DO 20 I = 1.10
|> [...]
|> First of all the blow up was due to the misreading of a superscript
|> in creating the formal specs for the program from the mathematics.
|> The program was in assembler; the assembly program correctly reflected
|> the specs; the specs were wrong.
|> 
|> The comma-period bug was in an ephemerides program at Johnson Space
|> Center.  It was not a real time program; it was a data analysis program.
|> The bug was caught because the output was palpably wrong.
|> 
|> The sequence of events went through several authors who rearranged
|> history bit by bit (you should excuse the expression) until the proper
|> moral was reached.

Well, not quite.  The proper moral is that all programming languages
(even informal specification languages) have contexts in which single
character errors can lead to linguistically correct programs which
don't compute the intended functionality.  The moral often stated
instead is that this is a bad feature of Fortran.  While Fortran
could indeed have been designed better, it is not the only language
with, or even the most severly affected by, this kind of problem.

-- 
J. Giles

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <1992Dec8.172551.16780@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. G
iles) writes:

[stuff deleted]
>
>Well, not quite.  The proper moral is that all programming languages
>(even informal specification languages) have contexts in which single
>character errors can lead to linguistically correct programs which
>don't compute the intended functionality.  The moral often stated
>instead is that this is a bad feature of Fortran.  While Fortran
>could indeed have been designed better, it is not the only language
>with, or even the most severly affected by, this kind of problem.
>
You make a good point. Perhaps the modern equivalent of that Fortran
single-keystroke bug is my favorite bit of C code (and no, I don't
want to bash C, just point out how common these flukes are):

   int x;
   ...
   x = 1;
   while (x <= 10);
   { 
      printf("%d\n", x);
      x++;
   }

For 10 points on your grade: what is printed? Why?
Try explaining it to a freshman.

Any similar idiosyncracies in Ada? 

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <1992Dec9.060218.23940@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman)
 writes:

>In article <1992Dec8.172551.16780@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. 
Giles) writes:

>[stuff deleted]
>>
>>Well, not quite.  The proper moral is that all programming languages
>>(even informal specification languages) have contexts in which single
>>character errors can lead to linguistically correct programs which
>>don't compute the intended functionality.  The moral often stated
>>instead is that this is a bad feature of Fortran.  While Fortran
>>could indeed have been designed better, it is not the only language
>>with, or even the most severly affected by, this kind of problem.
>>
>You make a good point. Perhaps the modern equivalent of that Fortran
>single-keystroke bug is my favorite bit of C code (and no, I don't
>want to bash C, just point out how common these flukes are):

>   int x;
>   ...
>   x = 1;
>   while (x <= 10);
>   { 
>      printf("%d\n", x);
                       ^^^
>      x++;
>   }

>For 10 points on your grade: what is printed? Why?
>Try explaining it to a freshman.

Nothing is printed.  You built an infinite loop.  This is hard to
understand?  You made a while loop with an empty body and a condition
that is never met because you never increment x.  Your freshmen don't
get this?

>Any similar idiosyncracies in Ada? 

Single character ones?  Probably not, but that just indicates that Ada
is incredibly more verbose than C.  One of the things I DISlike about
it, by the way.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Robb Nebbe]

Michael Feldman:

   int x;
   ...
   x = 1;
   while (x <= 10);
   { 
      printf("%d\n", x);
      x++;
   }

For 10 points on your grade: what is printed? Why?
Try explaining it to a freshman.


Fred McCall:
 
Nothing is printed.  You built an infinite loop.  This is hard to
understand?  You made a while loop with an empty body and a condition
that is never met because you never increment x.  Your freshmen don't
get this?

Me:

Good syntax means that code should do what it looks like it should do. The
above code is an example of less than optimal bordering on poor language
syntax. The reason being that many compilers don't detect that what is
obviously wrong code is wrong. On top of that the problem is rather inocuous
and if I didn't know that the problem was there I might miss it when reading
through the code. Basically the presence of a typo must be detected by having
your program hang. A far from optimal situation.

The far worse problem with C syntax is the one that caused the problem for
ATT. (This is all second hand so anyone in the know should correct me if I'm
wrong.) A programmer had left out a break in a switch statement. I don't
know the what the actual code was like by a switch looks like this.

   switch (x)
   {
      case 1:
         printf("x == 1\n");
         break;
      case 2:
         printf("x == 2\n");
         break;
      default:
         printf("x != 1 && x != 2\n");
   } 
   printf("done");

The break is necessary to leave the switch because the cases only serve as
labels and execution will fall through to the next case statement. This is a
case (no pun) where assembler shows through the C syntax. The machine code that
is generated for the switch is a jump table based on the value of x. At the end
of the statements another jump is required to avoid executing the rest of the
code from the other case statements. 

The fact that these problems exist in C is well known and most C texts point
them out. I would like to point out that these idiosyncracies have not
prevented C from being succesfully used in a phenomenal amount of code.

People need to put C in perspective. When people started using C it was 
because the choice was between assembler and C for many projects. For larger
projects the choice was between something like FORTRAN with some assembler
and C. My experience in mixing assembler and FORTRAN is very limited but it is
far from a trivial endevour. In both cases I would unhesitatingly choose C.

Now there are other choices such as Ada for doing programs that interface with
the hardware. Why do people keep using C? A lot of it has to do with inertia.
Another reason that we shouldn't forget is that a good C/C++ programmer can
turn out some very high quality code and if it aint broke don't fix it. In 
fact I would go as far as to say that well written C/C++ code is almost as
readable as Ada.

The problem with Ada is that it is a lot more difficult to do code generation
in my head ;-) Some of you will scoff but my education is in computer
engineering (thus hardware) and there is a tremendous amount a satisfaction in
knowing what it is that I am telling the hardware to do and not just in the
abstract sense.

When I program in Ada this sense of satisfaction is just not there. Programming
in C is sort of like making a piece of furniture yourself from scratch and
programming in Ada is like buying a kit. 

However I put such personal feelings aside when I have to do a project because
my level of confidence in 5000 lines of Ada is definitely higher than my
level of confidence in 5000 lines of C/C++. This isn't that I'm a better
programmer in Ada than in C/C++. To the contrary I'm sure that I master C
better than Ada but I probably know Ada better than C++. The reason is that
when I write code in Ada it usually won't compile if it wasn't what I meant.
In C/C++ the compiler isn't as helpful. For novice Ada programmers however this
is viewed as frusterating because the compiler won't except their code and it
is what they mean :^)

Michael Feldman:
|> >Any similar idiosyncracies in Ada? 

Fred McCall:
|> 
|> Single character ones?  Probably not, but that just indicates that Ada
|> is incredibly more verbose than C.  One of the things I DISlike about
|> it, by the way.

Me:

Actually the fact that Ada is verbose has absolutly nothing to do with the
fact that it doesn't have any similar idiosyncracies. The difference is that
the syntax of Ada was studied to avoid such problems and this wasn't a 
concern when they thought up the syntax for C. If they designers of C had been
interested in avoiding such problems it wouldn't have been too hard.

Robb Nebbe                nebbe@lglsun.epfl.ch

P.S. If you don't put the breaks in the switch it would print the following
if x == 1:

x == 1
x == 2
x != 1 && x != 2
done

with breaks and x == 1 it works as one would expect printing

x == 1
done

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Tucker Taft]

In article <1992Dec11.163811@lglsun.epfl.ch> 
  nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

> . . .
>The problem with Ada is that it is a lot more difficult to do code generation
>in my head ;-) Some of you will scoff but my education is in computer
>engineering (thus hardware) and there is a tremendous amount a satisfaction in
>knowing what it is that I am telling the hardware to do and not just in the
>abstract sense.
>
>When I program in Ada this sense of satisfaction is just not there. Programmin
g
>in C is sort of like making a piece of furniture yourself from scratch and
>programming in Ada is like buying a kit. 

I tend to agree with this assessment of Ada 83.

One of our goals for Ada 9X has been to give system programmers
back this feeling of satisfaction, so that you can do "code generation
in your head" for most Ada constructs.  In other words,
you can predict about how many machine instructions (and
generally which ones ;-) will be generated for each
construct in your program.  For a real-time embedded language,
this seems particulary important.

For example, an allocator in Ada 9X will be defined in terms
of a call on an appropriate Allocate procedure, user-replacable on
an access-type by access-type basis.
Similarly, a call on an instantiation of Unchecked_Deallocation
becomes a call on an appropriate user-replacable Deallocate routine,
preceded if appropriate by a call on a user-defined Finalize routine.

We have also provided the ability to create an access value
designating a declared variable, so long as it is marked "aliased,"
coupled with more control over by-reference vs. by-copy
parameter passing.

We also allow access to subprograms, allowing a pointer to
a procedure to be passed for the purpose of a call-back,
iteration over a data structure, etc.  This avoids some of
the heaviness and somewhat more-difficult-to-predict performance
of generics for certain simple situations.

Finally, the protected type feature is designed to allow
the construction of synchronization primitives with predictable
performance, including things like mailboxes, queues,
counting semaphores, etc.

Given some of these features, we hope that Ada 9X
will provide both the safety and high-level aspects
of Ada 83, but also the more "down-to-earth" feel appropriate for
systems programming, when you want it.

We would appreciate any specific suggestions about this 
issue of "control" or "predictability" of implementation
model, as it relates to systems programming in Ada 9X.

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <1992Dec11.132942.24054@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>
>>For 10 points on your grade: what is printed? Why?
>>Try explaining it to a freshman.
>
>Nothing is printed.  You built an infinite loop.  This is hard to
>understand?  You made a while loop with an empty body and a condition
>that is never met because you never increment x.  Your freshmen don't
>get this?

Sure they get it. I just don't want to take my time or theirs on this
kind of silliness. Which is why I keep saying that C should be
everyone's second language and nobody's first.
>
>>Any similar idiosyncracies in Ada? 
>
>Single character ones?  Probably not, but that just indicates that Ada
>is incredibly more verbose than C.  One of the things I DISlike about
>it, by the way.
>
You're certainly entitled to your opinion. I'm not down on C. I'd
rather train my teenager on a nice, verbose, safe car and give him
the keys to the Porsche after he's proven himself on the Chevy.
Less chance he'll waste his time crashing and burning. And the 70% or
more of the freshman teachers who are going to Ada or sticking with
Pascal (only slightly less verbose than Ada) agree.

Please - no more language wars.

Mike

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[John Nestoriak III]

In <1992Dec11.210404.2480@inmet.camb.inmet.com> Tucker Taft writes:
>One of our goals for Ada 9X has been to give system programmers
>back this feeling of satisfaction, so that you can do "code generation
>in your head" for most Ada constructs.  In other words,
>you can predict about how many machine instructions (and
>generally which ones ;-) will be generated for each
>construct in your program.  For a real-time embedded language,
>this seems particulary important.

Are there plans to add bitwise operations to Ada 9X?  Lack of
built in shift operators was a disappointing discovery for me.
I know that Ada is a high order language and therefor less suitable
for manipulating bits than say C, but there are high level functions
that need to manipulate bits.  I'm thinking in particular of
compression routines.  The project I work on is Ada but we had to
implement compression using C.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Tucker Taft]

In article <19921211.142820.329@almaden.ibm.com> 
  jnestoriak@vnet.ibm.com (John Nestoriak III) writes:

>In <1992Dec11.210404.2480@inmet.camb.inmet.com> Tucker Taft writes:

>>One of our goals for Ada 9X has been to give system programmers
>>back this feeling of satisfaction, so that you can do "code generation
>>in your head" for most Ada constructs.  In other words,
>>you can predict about how many machine instructions (and
>>generally which ones ;-) will be generated for each
>>construct in your program.  For a real-time embedded language,
>>this seems particulary important.
>
>Are there plans to add bitwise operations to Ada 9X?  Lack of
>built in shift operators was a disappointing discovery for me.
>I know that Ada is a high order language and therefor less suitable
>for manipulating bits than say C, but there are high level functions
>that need to manipulate bits.  I'm thinking in particular of
>compression routines.  The project I work on is Ada but we had to
>implement compression using C.

Yes.  We are planning to add "modular types" to Ada 9X,
which are unsigned, wrap-around types with a user-specified
modulus (normally a power-of-2).  These types will have +/-, etc., 
bit-wise and, or, xor, and not, as well as a language-defined
generic package that provides shift operations.  This
package is intended to be recognized by the compiler, so
that these shift operations result in inline machine instructions for
shifting.

Here is the tentative syntax:

   type Unsigned_16 is mod 2**16;  -- declare a 16-bit unsigned type

   package Shift_16 is new System.Shifts(Unsigned_16); use Shift_16;
                                   -- Get the shift functions
   X : Unsigned_16 := 16#00FF#;
   Y, Z : Unsigned_16;
begin
   Y := Left_Shift(X, 5);          -- Try them out
   Z := X and Y;
   if Z /= 16#00E0# then
       Put_Line("Send the 9X compiler back"); -- ;-)

etc...

S. Tucker Taft  stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Pascal Obry]

Fred,

> Single character ones?  Probably not, but that just indicates that Ada
> is incredibly more verbose than C.  One of the things I DISlike about
> it, by the way.

Why do you use english ?

( > @ - + / ~ $

==============================
Because I'am the only one to know this language I put below the dictionary :

> this
( try
$ word
+ it
, -
/ is
@ language
~ without
==============================


I like Ada because you can *read* it. And this seem to be one of the most
important thing about a language. With goods choices for the identifier, you
can read an Ada progam like a text, you don't have to translate what you read.

You write a program one time, but how many time you read it ?

Pascal.
--

-------------------------------------------------------------------------------
--  Pascal OBRY								     --
--  Room 2D-337				e_mail : obry@bellcore.com  	     --
--  Bellcore								     --
--  445 South Street			voice : 1 - 201 829 4039	     --
--  Post Office Box 1910		FAX   : 1 - 201 829 5981	     --
--  Morristown, New Jersey 07962-1910					     --
-------------------------------------------------------------------------------

  `` inheritance is surely a good answer, but who knows the question ? ''

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Bob Kitzberger]

obry@flash.bellcore.com (Pascal Obry) writes:


>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.

It is rare that I feel that Ada code is too verbose.  One of the instances
that comes to mind is the syntax for representation specifications, which
basically require duplicating the type definition just to provide the repspec.
For hundreds of lines of type specifications (e.g. a protocol definition)
the doubling of line count hinders maintenance (i.e. each change to a
data structure requires at least two changes: one in the type definition,
and one in the rep spec.)  OH well.

What is much, much more frustrating are the verbose, useless commenting
standards that one often finds on DoD projects.    What was once a
simple subprogram specification, with descriptive identifer names,
too often becomes a morass of useless information, often several
screens full of junk that some DoD or corporate coding standard requires.
Grrrrr.

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Fergus Jam es HENDERSON]

mfeldman@seas.gwu.edu (Michael Feldman) writes:

>You make a good point. Perhaps the modern equivalent of that Fortran
>single-keystroke bug is my favorite bit of C code (and no, I don't
>want to bash C, just point out how common these flukes are):
>
>   int x;
>   ...
>   x = 1;
>   while (x <= 10);
>   { 
>      printf("%d\n", x);
>      x++;
>   }

A good compiler would give a warning that the call to printf was
unreachable code. The only compiler I have available, gcc, unfortunately
doesn't give any such warning. But the Pascal-subset compiler I wrote (as one
of the projects for a 3rd-year subject) gives the following warnings for
the equivalent Pascal code:

warning: variable 'x' is not used after assignment, so assignment has no effect
warning: 'while' statement will cause an infinite loop

>Any similar idiosyncracies in Ada? 

The difference between '<' and '>' is only a single keystroke.
More insidious perhaps is the difference between '<' and '<='.
So it can happen even in Ada. 

However I do agree that Ada syntax is less error-prone than C or Fortran.
This is not because it is verbose but rather because the Ada designers took
this issue into careful consideration. I believe that it would be quite
possible to design a syntax that was concise but that was no more error-prone
than Ada.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Fergus Jam es HENDERSON]

obry@flash.bellcore.com (Pascal Obry) writes:

>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.
>
>You write a program one time, but how many time you read it ?

When learning a foreign language, there is a critical point at which you
cease translating from the foreign tongue into your own and back again,
and start to *think* in the foreign language.

The same is true of programming languages. After a very short span of time,
you start to *think* in terms of the constructs that your programming
language offers. Once this point is reached, using symbols instead of
words makes very little difference to the readability. Indeed the more
verbose form may often be less readable. We all learn how to read
mathematical equations - would you prefer that they be spelt out using
"plus" instead of "+", etc.? If you want a language where programs read
like text, try COBOL. Personally I believe that many common programming
language constructs are better expressed symbolically.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <9234801.7095@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James
 HENDERSON) writes:
>
>A good compiler would give a warning that the call to printf was
>unreachable code. The only compiler I have available, gcc, unfortunately
>doesn't give any such warning. But the Pascal-subset compiler I wrote (as one
>of the projects for a 3rd-year subject) gives the following warnings for
>the equivalent Pascal code:
>
>warning: variable 'x' is not used after assignment, so assignment has no effec
t
>warning: 'while' statement will cause an infinite loop

This is particularly good "advising" on the part of the compiler. A good
compiler is really a rule-based system, with lots of heuristics that
represent the domain expertise (potential logic errors). Most compiler
writers don't bother. The syntax and associated semantics of a carefully
designed language should work to minimize this sort of error anyway.

In the Pascal case, I believe that whether a null statement is legal
turns out to be implementation dependent. Great standard.
>
>>Any similar idiosyncracies in Ada? 
>
>The difference between '<' and '>' is only a single keystroke.
>More insidious perhaps is the difference between '<' and '<='.
>So it can happen even in Ada. 
Well, this is a bit different. "+" and "*" are single keystrokes too.
Arithmetic operators generally are. At least the operator is saying what it
means a little more clearly.

A better Ada example is the problem of procedure specifications vs. bodies.

PROCEDURE P;

is a valid statement in most contexts, so

PROCEDURE P;
BEGIN
  -- something
END P;

will often lead to propagation errors. This is confusing to students
because the error messages don't point to the real error location.
Try it on your favorite compiler; most Ada compilers have little or
no "expertise" that would catch this. Ada/Ed picks up some of it;
discussion with the GNAT folks informs me that their parser has a
lot of this kind of intelligence. 

But at least the ";" vs. "IS" problem is picked up _somewhere_ as a
compilation error. The single keystroke ";" problem in C arises because
people carelessly type extra semicolons where they don't belong. The
magnitude of the logic bug is far out of proportion with the magnitude
of the keying error. These things should (somehow) be more proprtionate.

Intuitively, in Ada they are. Having taught intro-level Ada to many 
hundreds, if not thousands, of students, I have found quite consistently
that - at that level - a program that compiles without errors will
_generally_ run without really strange behavior. Of course, this does
not prevent students from writing programs with logic errors, but
those are generally _logic_ errors and not _keying_ errors.

I have had very many students and colleagues who have studied and used
both Ada and C. I've never done a formal survey, but my informal survey -
done as far as possible without bias, leads me to a fairly form conclusion
that the real work in coding an Ada program (design questions aside!)
is in getting it through the compiler, while the real work in coding
a C program is in finding the reasons for the unexpected run-time
behavior. I am NOT arguing Ada's "superiority" in any global sense,
just pointing out where the real workload seems to be in both languages.
(At least this is true in the environments I have worked in.)
>
>However I do agree that Ada syntax is less error-prone than C or Fortran.
>This is not because it is verbose but rather because the Ada designers took
>this issue into careful consideration. I believe that it would be quite
>possible to design a syntax that was concise but that was no more error-prone
>than Ada.
>
Programmers seem to have a "thing" about verbosity. Ada's designers were
quite open about their intention that Ada code be easier to read than to write,
because as Pascal Obry pointed out yesterday, a program is written once but
read hundreds of times.

Mike

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <1992Dec11.163811@lglsun.epfl.ch> nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

>Michael Feldman:

>   int x;
>   ...
>   x = 1;
>   while (x <= 10);
>   { 
>      printf("%d\n", x);
>      x++;
>   }

>For 10 points on your grade: what is printed? Why?
>Try explaining it to a freshman.


>Fred McCall:
> 
>Nothing is printed.  You built an infinite loop.  This is hard to
>understand?  You made a while loop with an empty body and a condition
>that is never met because you never increment x.  Your freshmen don't
>get this?

>Me:

>Good syntax means that code should do what it looks like it should do. The
>above code is an example of less than optimal bordering on poor language
>syntax. 

It looks like it does what it should do to me, other than the abysmal
and unnecessary use of braces and indentation.  It's the language's
fault that poor coders can write poorly formatted code?

>The reason being that many compilers don't detect that what is
>obviously wrong code is wrong. On top of that the problem is rather inocuous
>and if I didn't know that the problem was there I might miss it when reading
>through the code. Basically the presence of a typo must be detected by having
>your program hang. A far from optimal situation.

Well, I prefer to think of it as the presence of a typo must be
detected by knowing the language -- a situation that is hardly
peculiar to C, and that is, in fact, pretty much a prerequisite for
writing working code in ANY language.

>The far worse problem with C syntax is the one that caused the problem for
>ATT. (This is all second hand so anyone in the know should correct me if I'm
>wrong.) A programmer had left out a break in a switch statement. I don't
>know the what the actual code was like by a switch looks like this.

>From reports I've seen, this isn't what caused the problem.

>   switch (x)
>   {
>      case 1:
>         printf("x == 1\n");
>         break;
>      case 2:
>         printf("x == 2\n");
>         break;
>      default:
>         printf("x != 1 && x != 2\n");
>   } 
>   printf("done");

>The break is necessary to leave the switch because the cases only serve as
>labels and execution will fall through to the next case statement. This is a
>case (no pun) where assembler shows through the C syntax. The machine code tha
t
>is generated for the switch is a jump table based on the value of x. At the en
d
>of the statements another jump is required to avoid executing the rest of the
>code from the other case statements. 

Gee, once again one is expected to know the language to write working
code in the language.  Funny how that works.  And if I implement the
wrong algorithm in Ada, it will tell me that I've made an error?

Just by the way, I believe that the actual problem was caused by
someone who put a 'break' statement inside an 'if', with the intention
of exiting the 'if' from the middle.  Of course, this doesn't work,
and he actually wound up leaving an enclosing loop prematurely.  It
was something like that, anyway.  The problem was the PRESENCE of a
'break', not the absence of one.

>The fact that these problems exist in C is well known and most C texts point
>them out. I would like to point out that these idiosyncracies have not
>prevented C from being succesfully used in a phenomenal amount of code.

>People need to put C in perspective. When people started using C it was 
>because the choice was between assembler and C for many projects. For larger
>projects the choice was between something like FORTRAN with some assembler
>and C. My experience in mixing assembler and FORTRAN is very limited but it is
>far from a trivial endevour. In both cases I would unhesitatingly choose C.

>Now there are other choices such as Ada for doing programs that interface with
>the hardware. Why do people keep using C? A lot of it has to do with inertia.
>Another reason that we shouldn't forget is that a good C/C++ programmer can
>turn out some very high quality code and if it aint broke don't fix it. In 
>fact I would go as far as to say that well written C/C++ code is almost as
>readable as Ada.

Personally, I find well-written C a lot MORE readable than Ada.  But I
think the point is well taken.  It is possible to write opaque code in
ANY language.

>The problem with Ada is that it is a lot more difficult to do code generation
>in my head ;-) Some of you will scoff but my education is in computer
>engineering (thus hardware) and there is a tremendous amount a satisfaction in
>knowing what it is that I am telling the hardware to do and not just in the
>abstract sense.

>When I program in Ada this sense of satisfaction is just not there. Programmin
g
>in C is sort of like making a piece of furniture yourself from scratch and
>programming in Ada is like buying a kit. 

>However I put such personal feelings aside when I have to do a project because
>my level of confidence in 5000 lines of Ada is definitely higher than my
>level of confidence in 5000 lines of C/C++. This isn't that I'm a better
>programmer in Ada than in C/C++. To the contrary I'm sure that I master C
>better than Ada but I probably know Ada better than C++. The reason is that
>when I write code in Ada it usually won't compile if it wasn't what I meant.
>In C/C++ the compiler isn't as helpful. For novice Ada programmers however thi
s
>is viewed as frusterating because the compiler won't except their code and it
>is what they mean :^)

>Michael Feldman:
>|> >Any similar idiosyncracies in Ada? 

>Fred McCall:
>|> 
>|> Single character ones?  Probably not, but that just indicates that Ada
>|> is incredibly more verbose than C.  One of the things I DISlike about
>|> it, by the way.

>Me:

>Actually the fact that Ada is verbose has absolutly nothing to do with the
>fact that it doesn't have any similar idiosyncracies. The difference is that
>the syntax of Ada was studied to avoid such problems and this wasn't a 
>concern when they thought up the syntax for C. If they designers of C had been
>interested in avoiding such problems it wouldn't have been too hard.

Well, there is just a bit more to it that that, and I think someone
back there a while ago posted a list showing a few 'peculiar'
structures for Ada, as well.  I wish I still had it.

>Robb Nebbe                nebbe@lglsun.epfl.ch

>P.S. If you don't put the breaks in the switch it would print the following
>if x == 1:

>x == 1
>x == 2
>x != 1 && x != 2
>done

This is a surprise?  If you don't put in the print statements it
doesn't print anything.  These two results are about equally
surprising. 

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <OBRY.92Dec11164203@cheesesteak.flash.bellcore.com> obry@flash.bellcore.com 
(Pascal Obry) writes:


>Fred,

>> Single character ones?  Probably not, but that just indicates that Ada
>> is incredibly more verbose than C.  One of the things I DISlike about
>> it, by the way.

>Why do you use english ?

Because it's what everyone else speaks?  If this is your defense of
Ada, it is a poor one.  If you want something that 'everybody can
read', you should be using COBOL.  It was designed with the idea in
mind that MANAGERS should be able to look at a program and tell what
it does without knowing the language. 

>( > @ - + / ~ $

>==============================
>Because I'am the only one to know this language I put below the dictionary :

>> this
>( try
>$ word
>+ it
>, -
>/ is
>@ language
>~ without
>==============================


>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.

Golly gee whiz, you have to actually KNOW THE LANGUAGE to read it.
Horrors!  Oddly enough, I expect anyone reading a program and
expecting to understand it to be able to read the language.  If you
hand somebody a bunch of Ada code, they're going to be able to read
and understand it?  Gee, how is that going to work?  They're going to
know what pragmas do, things like packages and generics, etc.?  I
don't THINK so.

>You write a program one time, but how many time you read it ?

As many times as I need to?  Why is this a problem?

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!csc.ti.com!til]

In <1992Dec11.213147.24000@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman
) writes:

>In article <1992Dec11.132942.24054@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
 (fred j mccall 575-3539) writes:
>>
>>>For 10 points on your grade: what is printed? Why?
>>>Try explaining it to a freshman.
>>
>>Nothing is printed.  You built an infinite loop.  This is hard to
>>understand?  You made a while loop with an empty body and a condition
>>that is never met because you never increment x.  Your freshmen don't
>>get this?

>Sure they get it. I just don't want to take my time or theirs on this
>kind of silliness. Which is why I keep saying that C should be
>everyone's second language and nobody's first.

I agree.  I feel the same way about Ada, by the way.  There's simply
too much there to be teaching it to people as a first language.

>>
>>>Any similar idiosyncracies in Ada? 
>>
>>Single character ones?  Probably not, but that just indicates that Ada
>>is incredibly more verbose than C.  One of the things I DISlike about
>>it, by the way.
>>
>You're certainly entitled to your opinion. I'm not down on C. I'd
>rather train my teenager on a nice, verbose, safe car and give him
>the keys to the Porsche after he's proven himself on the Chevy.
>Less chance he'll waste his time crashing and burning. And the 70% or
>more of the freshman teachers who are going to Ada or sticking with
>Pascal (only slightly less verbose than Ada) agree.

Pascal tends to be a somewhat more appropriate choice for a first
language.  It's a nice protected environment with a limited set of
features. 

>Please - no more language wars.

I concur -- which is why I took exception to the original
characterizations of 'the C community'.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[J. Giles]

In article <1992Dec11.163811@lglsun.epfl.ch>, nebbe@lglsun.epfl.ch (Robb Nebbe)
 writes:
|> Michael Feldman:
|> 
|>    int x;
|>    ...
|>    x = 1;
|>    while (x <= 10);
|>    { 
|>       printf("%d\n", x);
|>       x++;
|>    }

One of the first things I do when a C program misbehaves is to check
the trivial pitfalls.  One of the things I look for is "compound
statements" that aren't the direct object for some control-flow
construct.  If I used C more frequently, I would be tempted to 
write a preprocessor which flagged such things.  In this case,
such a preprocessor would issue a warning that the `{' and `}'
were redundant.

Without explicitly looking for the above type of error, or having
an automated tool which looks for it on your behalf, this could be
a difficult to find error.  The problem is that programmers look
at code and *know* what it's supposed to do.  They tend to skim
the code looking for glaring errors. They miss this sort of thing
because it's next to invisible.  In a large code in which the location
of the problem is not easy to determine (like maybe this is in one
of 500 routines which *could* be causing the problem), this could
take some time to isolate.

Now, I think that the "compound statement" is a poor language design
feature.  This is one of the reasons I think so.  Therefore, it's one
of the features I'm most suspicious of when code goes wrong.  I would
prefer that C would have the following style syntax:

   int x
   ...
   x = 1
   while (x <= 10)
      printf("%d\n", x)
      x++
   endwhile

Now there's no way to mix-up where the `while' loop terminates.
The code is much easier to read and will have significantly
fewer errors of the "I know what this means, but it's not doing
it" variety.

-- 
J. Giles

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[John Bollenbacher]

God, don't you people ever tire of this?

--
-----------------------------------------------------------------------------
- John Bollenbacher                                        jhb@dale.cts.com -
- Titan Linkabit Corp.                                       (619) 552-9963 -
- 3033 Science Park Rd.                                                     -
- San Diego, Ca. 92121                                                      -
-----------------------------------------------------------------------------

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <1992Dec14.170421.18709@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>
>I agree.  I feel the same way about Ada, by the way.  There's simply
>too much there to be teaching it to people as a first language.
Well, you're certainly entitled to your opinion. Those of us who are
actually _doing_ it, and (most of) our students, like what they see.

We don't tell the students what a verbose, hairy, big, risky dinosaur
Ada is, so they somehow get the impression they can learn it. And they do.

We teach our infant children a subset of English (or German, or whatever),
and we teach our freshmen a subset of Ada. They learn the rest as they
grow up. It's a language you can grow into.
>
>Pascal tends to be a somewhat more appropriate choice for a first
>language.  It's a nice protected environment with a limited set of
>features. 
The downside is that vanilla Pascal (the ISO standard version) is much
too underpowered for the software engineering stuff (like separate
compilation) we want to do, even with first-years. So many teachers go
with Turbo. Only trouble is, Philippe has decided that Turbo for Unix
isn't worth his trouble, so yanking the kids off their PC's onto the
Unix boxes in the lab is impossible unless they switch to C...or Ada.

Mike Feldman

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <Bz9sHv.3B1@dale.cts.com> jhb@dale.cts.com (John Bollenbacher) write
s:
>God, don't you people ever tire of this?
>
I do.

Mike

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[enterpoop.mit.edu!bloom-picayune.mit.edu!mintaka.lcs.mit.edu!ogicse!uwm.e]

In <1992Dec15.024340.22575@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman
) writes:

>In article <1992Dec14.170421.18709@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
 (fred j mccall 575-3539) writes:
>>
>>I agree.  I feel the same way about Ada, by the way.  There's simply
>>too much there to be teaching it to people as a first language.
>Well, you're certainly entitled to your opinion. Those of us who are
>actually _doing_ it, and (most of) our students, like what they see.

There are also a lot of places that are teaching C as a first
language.  That doesn't make it any less a mistake, in my opinion. 

>We don't tell the students what a verbose, hairy, big, risky dinosaur
>Ada is, so they somehow get the impression they can learn it. And they do.

Substitute C for Ada in the above sentence and it makes equally good
sense.  I still don't think it's a good idea.  

>We teach our infant children a subset of English (or German, or whatever),
>and we teach our freshmen a subset of Ada. They learn the rest as they
>grow up. It's a language you can grow into.

As is any language.  I don't consider this a particularly good
argument for using it in a beginning class.

>>
>>Pascal tends to be a somewhat more appropriate choice for a first
>>language.  It's a nice protected environment with a limited set of
>>features. 
>The downside is that vanilla Pascal (the ISO standard version) is much
>too underpowered for the software engineering stuff (like separate
>compilation) we want to do, even with first-years. So many teachers go
>with Turbo. Only trouble is, Philippe has decided that Turbo for Unix
>isn't worth his trouble, so yanking the kids off their PC's onto the
>Unix boxes in the lab is impossible unless they switch to C...or Ada.

Then they should make the switch.  One would hope you're planning on
them learning more than one language, anyway.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[fred j mccall 575-3539]

In <OBRY.92Dec16094056@cheesesteak.flash.bellcore.com> obry@flash.bellcore.com 
(Pascal Obry) writes:


>>>Why do you use english ?
>>
>>Because it's what everyone else speaks?  If this is your defense of

>I hope you didn't mean *everyone*, because in this case you would have
>forgotten 3/4 of the world (and maybe more in the univers). Anyhow if you mean
>that you should travel a bit !

Well, I expect that I've travelled at least as much as most (all that
military time, you know), and I'll stand by that statement.  Why are
we speaking English here?  Why do all pilots and ATC centers speak it
(except those in the former Soviet Union -- and they'll probably wind
up changing over)?

>>Ada, it is a poor one.  If you want something that 'everybody can
>>read', you should be using COBOL.  It was designed with the idea in
>>mind that MANAGERS should be able to look at a program and tell what
>>it does without knowing the language. 

>I had to learn COBOL for one of my courses 5 years ago, and by the way it
>does very well what it is suppose to do : file manipulation and form to enter
>data.

[The attributions got screwed up somewhere along in here, since I said
part, but not all, of what is below with >>>.  Let's be careful out
there!] 

>>>I like Ada because you can *read* it. And this seem to be one of the most
>>>important thing about a language. With goods choices for the identifier, you
>>>can read an Ada progam like a text, you don't have to translate what you rea
d

>>>Golly gee whiz, you have to actually KNOW THE LANGUAGE to read it.
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>Horrors!  Oddly enough, I expect anyone reading a program and
>>>expecting to understand it to be able to read the language.  If you
>>>hand somebody a bunch of Ada code, they're going to be able to read
>>>and understand it?  Gee, how is that going to work?  They're going to
>>>know what pragmas do, things like packages and generics, etc.?  I
>>>don't THINK so.

>I don't agree here. let me take a small example :

>In C++ :

>	cout << "un text" << endl;
>	c++;
>	if (i) { ... };                 /* let suppose i is an integer */
>	for (k=0; k<4; k++) {...}

>In Ada :

>	text_io.put_line ("Un text");
>	c := c + 1;
>	if i = 1 then ... end if;
>	for k in 0 .. 3 loop ... end loop;

>I bet that people that don't know either C++ and Ada will understand the Ada
>code. Could we think the same of C++ code ? there is too much conventions
>in C/C++ :

Why would one expect (or want) people who do not know a language to be
looking at and evaluating code?

>	if (i) {..}
>		true if i = 1, you can invent that, you have to learn it

>	for (k=0; k<4; k++) {...}
>		first parameter is to initialize
>		second stop test
>		third whatever you want

>Ok, this is only one instruction. But don't you think that a whole program is
>a set of instructions.

>And we can find a lot of more exemple like this. But I don't want to start a
>language war.

Then why bring it up?  Is it standard practice where you are for
people who don't know a language to be evaluating, writing, or
maintaining code?  'Readability' is a red herring, except insofar as
it applies to people who know the language.  It applies not to 'funny
function names' or 'verboseness', but to the ability to build
constructs that someone who UNDERSTANDS the language has difficulty
deciphering the effect of.  This is certainly probably easier in C/C++
than in Ada, but that's not exactly germane.  It just says that people
who don't understand how to write readable code should probably
preferentially be working in a language that will TRY to force them to
(like Pascal or Ada).  Note, however, that this is certainly no
guarantee, since obscure or opaque code can be written in any
language. 

>Anyhow this is only one part of the readability. The low-level readability or
>instruction readability. I don't mean that an Ada algorithm of many lines will
>be easy to understand at the first look. But at least, I think it will be
>easy to follow line by line what it does.

As will the C++ program, if you 'speak' C++

>An Ada program does what it says.

So does any other program.  Your argument seems to boil down to saying
that Ada is 'better' because it can be understood by someone who
doesn't know Ada.  That is both irrelevant AND untrue.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Pascal Obry]

>>Why do you use english ?
>
>Because it's what everyone else speaks?  If this is your defense of

I hope you didn't mean *everyone*, because in this case you would have
forgotten 3/4 of the world (and maybe more in the univers). Anyhow if you mean
that you should travel a bit !

>Ada, it is a poor one.  If you want something that 'everybody can
>read', you should be using COBOL.  It was designed with the idea in
>mind that MANAGERS should be able to look at a program and tell what
>it does without knowing the language. 

I had to learn COBOL for one of my courses 5 years ago, and by the way it
does very well what it is suppose to do : file manipulation and form to enter
data.

>Why do you use english ?

Because it's what everyone else speaks?  If this is your defense of
Ada, it is a poor one.  If you want something that 'everybody can
read', you should be using COBOL.  It was designed with the idea in
mind that MANAGERS should be able to look at a program and tell what
it does without knowing the language. 

>( > @ - + / ~ $

>==============================
>Because I'am the only one to know this language I put below the dictionary :

>> this
>( try
>$ word
>+ it
>, -
>/ is
>@ language
>~ without
>==============================


>>I like Ada because you can *read* it. And this seem to be one of the most
>>important thing about a language. With goods choices for the identifier, you
>>can read an Ada progam like a text, you don't have to translate what you read

>>Golly gee whiz, you have to actually KNOW THE LANGUAGE to read it.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>Horrors!  Oddly enough, I expect anyone reading a program and
>>expecting to understand it to be able to read the language.  If you
>>hand somebody a bunch of Ada code, they're going to be able to read
>>and understand it?  Gee, how is that going to work?  They're going to
>>know what pragmas do, things like packages and generics, etc.?  I
>>don't THINK so.

I don't agree here. let me take a small example :

In C++ :

	cout << "un text" << endl;
	c++;
	if (i) { ... };                 /* let suppose i is an integer */
	for (k=0; k<4; k++) {...}

In Ada :

	text_io.put_line ("Un text");
	c := c + 1;
	if i = 1 then ... end if;
	for k in 0 .. 3 loop ... end loop;

I bet that people that don't know either C++ and Ada will understand the Ada
code. Could we think the same of C++ code ? there is too much conventions
in C/C++ :

	if (i) {..}
		true if i = 1, you can invent that, you have to learn it

	for (k=0; k<4; k++) {...}
		first parameter is to initialize
		second stop test
		third whatever you want

Ok, this is only one instruction. But don't you think that a whole program is
a set of instructions.

And we can find a lot of more exemple like this. But I don't want to start a
language war.

Anyhow this is only one part of the readability. The low-level readability or
instruction readability. I don't mean that an Ada algorithm of many lines will
be easy to understand at the first look. But at least, I think it will be
easy to follow line by line what it does.

An Ada program does what it says.

Pascal.

--

-------------------------------------------------------------------------------
--  Pascal OBRY								     --
--  Room 2D-337				e_mail : obry@bellcore.com  	     --
--  Bellcore								     --
--  445 South Street			voice : 1 - 201 829 4039	     --
--  Post Office Box 1910		FAX   : 1 - 201 829 5981	     --
--  Morristown, New Jersey 07962-1910					     --
-------------------------------------------------------------------------------

  `` inheritance is surely a good answer, but who knows the question ? ''

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[agate!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!caen!uvaarpa!vger.ns]

In article <1992Dec15.025733.22796@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
> In article <Bz9sHv.3B1@dale.cts.com> jhb@dale.cts.com (John Bollenbacher) wri
tes:
>>God, don't you people ever tire of this?
>>
> I do.
> 
> Mike
I do too.  Reminds me of what seventh grade boys do in locker rooms, but I'll
not take the analogy beyond that.
 
George

Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[Michael Feldman]

In article <2967.2b31602b@vger.nsu.edu> g_harrison@vger.nsu.edu (George C. Harr
ison, Norfolk State University) writes:
>In article <1992Dec15.025733.22796@seas.gwu.edu>, mfeldman@seas.gwu.edu (Micha
el Feldman) writes:
>> In article <Bz9sHv.3B1@dale.cts.com> jhb@dale.cts.com (John Bollenbacher) wr
ites:
>>>God, don't you people ever tire of this?
>>>
>> I do.
>> 
>> Mike
>I do too.  Reminds me of what seventh grade boys do in locker rooms, but I'll
>not take the analogy beyond that.
> 
>George
>
Funny thing, George. Every now and then my wife looks over my shoulder
when I'm reading this group, and she always chuckles at what she calls
"typical male pi**ing contests". She is still waiting to see a female
name on comp.lang.ada (she hasn't lucked into seeing one of Deborah's
posts).

Mike