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

[seas.gwu.edu!mfeldman@uunet.uu.net (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