(j3.2006) (SC22WG5.4192) WG5 Las Vegas Feb-2010/J3 m191 minutes 10-144

[Van Snyder]

On Tue, 2010-02-23 at 12:34 -0800, Toon Moene wrote:
> Van Snyder wrote:
> 
> > My colleagues view the failure to undertake any substantive development
> > of Fortran until 1990 as the major reason for the bad odor Fortran has
> > in computer science departments.  Now that Fortran is starting to be
> > taught in engineering departments again, it is exactly the wrong time to
> > take another 40-year development hiatus.
> 
> Fascinating - I just today realized how I keep explaining to colleagues 
> that Fortran is in no way going to die, and how we (i.e. WG5 and J3) are 
> on a straight path to keep the language relevant, and regularly updated, 
> especially when compared to C (last Standard: 1999, next Standard: 2014 
> ?) and C++ (last Standard 1998, next Standard: 201x).
> 
> So who's complaining ?

We were on a straight path that some propose ought now to dive over a
cliff into oblivion.

At meetings 189-191, and earlier meetings whose precise numbers I don't
rememeber, the sentiment was expressed by several PL22.3 members and
several non-PL22.3 attendees at WG5 meetings that the next revision of
the Fortran standard should be a "maintenance only" release.  That means
"nothing new will appear for at least ten years."  That's not "a
straight path to keep the language relevant."

JPL has substantial investment in long-lived Fortran programs, some
going back nearly fifty years.  These aren't just decks sitting on the
shelf gathering dust.  They are undergoing continuous development as
requirements and ambitions change.  I don't think JPL is alone.

Details and limitations of existing features have been identified as
obstacles to reducing labor cost or increasing reliability.  New
features have been identified as avenues to reduce ownership cost and
increase reliability.  I have suggested many changes aimed at these
problems to the Fortran committee since 1986.  I would have used
coarrays starting in 2000 if they had been part of the standard.

I suggested features for and changes in what became Ada to the
Department of Defense in about 1980, with JPL going so far as to send me
to a meeting at Purdue University expressly for the purpose of
confronting Colonel Whittaker concerning the requirements in what was
then "Tinman," which soon became "Ironman," then "Steelman."  I was a
reviewer of the four proposals, and voted for the one that became Ada in
1983, with comments concerning the inadequacy of the few facilities
aimed squarely at engineering and scientific problems.

The Fortran program suite that is perhaps JPL's most important one,
spacecraft navigation, consists of 65 or so programs, comprising about
six million lines.  The maintenance staff for that program has dwindled
from 7.5 work years per year to something like 1.5, primarily due to
retirements.

We're having trouble finding replacements.  Young people who could quite
easily learn enough Fortran in a month to be productive contributors,
and enough in six months to be experts, don't want Fortran on their
resum?s because they perceive Fortran to be obsolete and stagnant.

For that reason, a project was undertaken in 1996 to re-write the
navigation suite in C++.  They asked for 120 work years.  I calculated
that if they finished in 2002 and reduced maintenance cost for
navigation software to zero they would break even in 2023.  One guy
worked on the integrator for ordinary differential equations for 18
months and couldn't even produce a useful interface, let alone reproduce
any of the necessary functionality.

Two years ago the project returned to their sponsor and said "We're
almost finished; we've used up the 120 work years of funding you gave
us; we need only another 126 work years of funding."  The C++ and
Fortran versions were used side-by-side for the Mars Phoenix lander.
Proponents of the C++ replacement claim it worked.  Navigators who use
both programs say it doesn't work.  As demonstrated by the Mars Climate
Orbiter fiasco, this is really important software whose failure can cost
hundreds of millions of dollars.

As far as I can tell, the C++ version will need 20 work years per year
for the indefinite future.  This isn't quite the factor of six greater
than the historic staff of 7.5 that Les Hatton predicted, but it is a
factor of 13 more than the current staff of 1.5 for the Fortran program.
The C++ replacement is definitely neither a reduction in ownership cost
nor an improvement in reliability.  But we might be stuck with it.

The only way to make Fortran attractive to young people is to keep it on
a track to becoming and remaining a modern language, or, better yet, to
offer unique features aimed at reducing the cost and increasing the
reliability of engineering and scientific computing that aren't offered
by any other significantly-used language.  If we stop development now,
even if only for a ten-year hiatus, the perception of Fortran as an
irrelevant fossil will only be re-enforced.