From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public From: Craig Burley Subject: Re: Fortran or Ada? Date: 1998/09/26 Message-ID: #1/1 X-Deja-AN: 394999924 References: <36068E73.F0398C54@meca.polymtl.ca> <6u8r5o$aa4$1@nnrp1.dejanews.com> <6uenvf$g9a$1@nnrp1.dejanews.com> Organization: Cygnus Support Newsgroups: comp.lang.fortran,comp.lang.ada Date: 1998-09-26T00:00:00+00:00 List-Id: dewarr@my-dejanews.com writes: > In article , > > Craig Burley 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