Re: Fortran to Ada

[eachus@spectre.mitre.org (Robert I. Eachus)]

    A (possibly partly apocryphal--I wasn't at the final presentation)
incident from the early days of Ada:

    We were asked to recode some existing FORTRAN code in Ada and
report on the relative performace.  A quick line-for-line translation
resulted in an immediate CONSTRAINT_ERROR.  The fix was fairly obvious
and off to find the next one.

    Two weeks (and seventeen bug fixes) later we had an Ada version
that survived the regression suite developed for the FORTRAN version,
but it gave different answers.  (The seventeen bug number is amazing
since this was about 850 original SLOC, the fixed version was larger.)
So we made "the same" corrections in the FORTRAN source, and we had
two different language versions which produced identical output.  Now
finally we could do the benchmarking...

    The Ada version was significantly slower (about 25%) than the
original FORTRAN version and very slightly (about 2%) faster than the
fixed FORTRAN version.  But this code was in the OS scheduling
software.  When we put the fixed version in there, everything ran
faster.

    Then this was presented to senior management. At about slide two,
the presentation was halted to find out how such badly broken code
could get through quality control and out the door.  After standing
there for almost an hour, the presenter got to his next slide, and was
asked why he bothered presenting results with the "broken" FORTRAN. He
then explained that the fixes had yet to be accepted by QC, since the
new software didn't pass the regression tests...

    That meeting made the Ada group some enemies that lasted until
well after I left the company.

    I've since had many similar experiences, and my expectation has
become that ALL FORTRAN numerics code is full of bugs, even my own.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...