Re: Fortran or Ada?

[Craig Burley <burley@tweedledumb.cygnus.com>]

dewarr@my-dejanews.com writes:

> In article <y6sohhr11s.fsf@tweedledumb.cygnus.com>,
> 
>   Craig Burley <burley@tweedledumb.cygnus.com> wrote:
> 
> > IMO, you're absolutely right.  And, yes, a typo such as "**" for "*"
> > should produce a diagnostic, but I suspect both Fortran and C suffer
> > from this sort of thing much more than does Ada, simply because Ada
> > is a more recent language and was, I gather, more thoughtfully designed
> > than some other recent languages.
> 
> Craig, surely you do not know Ada in writing the above!

I didn't say I *did* know Ada -- in fact, I don't!

> The character * never has syntactic significance other
> than as a multiplication operator, and ** is exponentiation.

Oh, in that case, then, you're right, it's impossible to expect
a diagnostic for typos involving "normal math" expressions in a
language designed to support such things "natively".

> One could argue that it is unwise to use ** as exponentiation
> precisely because of this one character differentiation, but
> that seems a bit extreme to me!

Especially since an alternative, like BASIC's `^', still suffers
from a one-character mistake (a two-key-distance difference on
my keyboard, anyway).  Same for `+' vs. `-', etc.

What I thought might be the case was that `**' was substituted
in place of `*' in something non-mathematical, e.g. like C's
`char *foo;'.  In that example, such a typo can lead to really
hard-to-track-down behavior, and only programmers highly experienced
with that particular area of the language (C declarations) are
likely to spot it.  (These programmers will have tended to "trade
off" expertise in the application area.  While working at Cadence,
I once spotted exactly this sort of bug while looking over a
co-workers' shoulder as he and one or two others had been debugging
this bug, involving portability and reproducability problems, for hours.
The reason I was able to spot it wasn't due to any genius on my part --
in fact, I had little understanding of what the code was trying to do
in the larger sense, so I had no choice but to concentrate on the
minutiae.)

It's in the notations outside of the typical programmer's "life
expertise" that language designers must be extra-careful to
avoid constructs in which common typographical mistakes lead
to bizarre bugs, IMO.  And priority should be given to avoid
the most hard-to-see typos in general anyway: `.' vs. `,', `:' vs.
`;', `0' vs. `O', `1' vs. `l' vs. `I' vs. `!', and so on.

E.g. it is much worse that FORTRAN 77 allows the `.' typo for `,'
creating

	DO 10 I=1.6

than that it allows the `+' typo for `*' creating

	CIRC=PI+RADIUS

because the "expected" audience will spot the latter, "math" error
much more easily than the error in the imperative construct (DO).

Similarly, C's `=' vs. `==' is a pretty bad problem -- though long-
sinced worked around using "clever" software, which helps not one
whit when reading printouts -- compared to its `+' vs. `-' in
ordinary expressions, because only readers highly experienced with
C itself have become accustomed to spotting the former error as
easily as most readers of C code would spot the latter (assuming
they know the algorithm).

It's tempting to avoid the "math" error by further requiring
more verbosity in the language design.  I believe that, in a
language designed for use by Western scientists -- e.g. any language
one expects to replace Fortran within 50 years -- that would be
a mistake, or at least should be carefully balanced against
the flip side of the problem, e.g., an experienced mathematician
might be more able to spot the bug in `PI+RADIUS' than in
`(plus (pi radius))', having already become accustomed to
lexical-infix notation before ever encountering the new language.

In summary: language designers should try and restrict their use
of narrow lexical distinctions to those areas with which the
expected audience is already very familiar, and, in other areas,
ensure that common typographical errors are most likely to cause
expressions that are immediately discoverable as invalid expressions
in the language.
-- 

"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson    burley@gnu.org