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

[cochiti.lanl.gov!jlg@lanl.gov (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