The future of Fortran

[xanthian@qualcomm.com (Kent Paul Dolan)]

Followups diverted only to comp.lang.fortran.

In article "Re: Object-oriented Fortran vs. Ada 95?"
<312B6418.27E7@escmail.orl.mmc.com>, Ted Dennison
<dennison@escmail.orl.mmc.com> wrote:

> As for OOP, I think I'd have to agree with your argument. Fortran was
> not designed with OOP in mind. Merrily tacking on features to the 
> language when there isn't a desperate need for them will only hasten 
> its decent into entropy. Better to let Fortran live (or die) as 
> Fortran.

As a person at one time credited with yelling loudly enough in
comp.lang.fortran that the Fortran8x committee made Fortran 90 a rich
upgrade of Fortran 77 rather than a meager one, I'll have to repeat what I
said then:  if a language doesn't keep up with modern programming
technology, all the inertia generated by all the dusty decks in the world
won't keep it alive, and then suddenly you have a new generation of
hardware with all those dusty decks uncompilable.

Do you remember how many generations of 1401 machine code emulators were
written and sold because the original source code was
uncompilable/unlocatable?  This is not the model of computing most math
intense programmers would want Fortran's future to emulate.  Math intense
programming tends not to want to run in emulation mode.

Kicking and screaming all the way, FORTRAN 77 gained modules, rich
parallel programming syntax, structured records, and a lot more,
attempting to catch Fortran up with Pascal and Ada, and in some ways
(array notation) surpass them.  The ability to express things Fortran
programmers had always been doing with clumsy work-arounds for the
language's lacks (commons of arrays of scalars where arrays of records
were meant, for example), simply and naturally in constructs now part of
an upwardly compatible language standard, is a win few Fortran 90
programmers would be willing to give back, I'd bet.

Thinking "we never use OOP, why do we need it in Fortran" is probably
wrong-headed.  I was, and I'm sure many other Fortran programmers were,
conceptually creating abstract data types decades before OOP gave
programmers clean facilities for that purpose, and a vocabulary of
"objects" with which to talk about it; just in self defense to survive the
problem of programming in the large.

Adding those conceptual, implicit OOP "tricks" to become concrete,
explicit features of the language can only assist Fortran's survival into
the third millennium, and improve the vocabulary math intensive
programmers use to express to one another how they "package stuff up" to
make big programming projects mesh.

Like the Fortran 8x standards committee, the Fortran 9x committee will
have its crowd of naysayers, its herd of compiler vendors bellowing for
"only minimal editorial corrections in an otherwise perfect standard",
freely translated as "we want to milk our current cash cow product for
another decade without substantial new programming investment".  These
forces should be resisted, for the sake of Fortran, and the best models of
OOP should be consulted for the difficult task of designing an upwardly
compatible OOP extension of the Fortran 90 standard.

[Those of you who were around for my previous tirade will notice that I've
mellowed a lot in the last decade.  Starting a second family late in life
will do that to you; it's hard to get emotional when it's all you can do
to stay awake.  Two AM feedings are the pits.  One kid in grad school at
UNC, he'll teach English, one married with a kid of his own, one a
freshwoman at W&M, and one seven weeks old today.  Sheesh!]

-- 
Xanthian.                  | "..want the consequences of what you want.." | 
Kent, the man from xanth.  |        Neil A. Maxwell, LDS Apostle          |
Kent Paul Dolan            ------------------------------------------------
xanthian@{well,qualcomm}.com     Jobhunting?  Check www.qualcomm.com!