Q: Fortran 'era' - 66/77/90/95/03/08? [Was: Re: [Beowulf] Green Cluster?]

[Brian Dobbins]

Hi everyone,

I don't know what the language of the 21st century will be like,
> but it will be called FORTRAN.
>                        -C.A.R Hoare



  I know this was made in a somewhat off-topic thread touching on politics,
but I couldn't resist adding my two cents and seeing what other people see
from codes these days.  This post stems from a few conversations I've had
with people at Yale on development practices and languages, and also from
the realization that a university operates quite differently (I think) than
research labs or corporations.  Thus, this list is a great way to ping the
'real world' and learn from some different points of view...

  See, I love Fortran.. or, more specifically, sensible Fortran.  The
problem is that there's a *lot* of nightmare-inducing Fortran code (mostly
F77/F66) that is chock-full of things like computed GOTOs, 'equivalence'
statements, Hollerith constants, variable names that need their own Rosetta
stone to comprehend, etc.  To borrow an image from Douglas Adams, that stuff
can be like Vogon Poetry - it's torture to me, plain and simple, but somehow
other people love it.  ;-)

  Now, I grew up on C/C++, and I definitely agree that Fortran is going to
be the language of choice for codes (in the physical sciences) in the near
to mid-distant future, but *as* a C/C++ guy who has seen more than his fair
share of 'object oriented' inspired abstraction where it was most definitely
not warranted, I worry a little bit about people leapfrogging from the
ancient F66/F77 ways to, "Ooh, someone said Fortran 2003 has lots of OO
features!  Let's redesign everything with 34,782 levels of abstraction!".  I
cringe at the thought.  On the plus side, as evidenced by the fact that much
of the code I see *is* so old, it seems many developers aren't keen on
adopting 'new' things in their language, but on the other, with the size of
the projects faced in scientific computing and the increasing importance of
multi-threading or even well-designed MPI-based parallelism, *lots* of
people in the physical sciences could benefit from people with a software
engineering background... one that *often* comes with C/C++ familiarty and
its assorted demons.  D'oh.

  In terms of the in-house applications I work on, I readily use F90's
allocatable arrays and parse tons of command-line arguments, since I figure
having flexible codes that are easy for a user to alter without recompiling
are worth their weight in gold, and I also tend to use array syntax
(sometimes with explicit indices for clarity) to eliminate some loops and
make the code more natural in the mathematical sense.  And, of course, I use
more descriptive variable names and modules for organizing things.  In terms
of the complexity of the data structures and flow, though, I try not to mess
with simplicity much - this seems to not only be a half-decent application
of the 'KISS' principle, but it also lets people who are not too familiar
with F90 still understand what is going on since most things are left
relatively unchanged.  The above 'changes' to the F66/F77 base often seem a
bit radical to some, so I'd love to know what people see, in general, at
other places.  I know some places such as NASA run training classes on the
advanced features of F2003 (and even F2008, I think!), and surely the
National Labs do, too, but are modern codes taking advantage of such
features in any real capacity yet?  (Ex: IBM's XLF already has procedure
pointers implemented, so *surely *someone asked for that?  Is it being used
in any open production codes?)

  In other words, what 'era' of Fortran do most people find themselves in,
and are things changing?

(PS.  I hope nobody minds the title change -- I figured it was 'different
enough' from "Green Computing" to warrant it!)

Cheers,
  - Brian


Brian Dobbins
Yale Engineering HPC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20080722/eed83aa3/attachment.html>