Fortran pros and cons (was Re: Coding style article with interesting section on white space)

[beliavsky at aol.com]

Michael Tobis wrote:

> > Fortran programmers are generally happy with the portability of the
> > language.
>
> Until they try to port something...? Honestly, I can't imagine where
> anyone would get this impression.

>From the fact that Fortran has been used on hundreds of platforms and
that many portable libraries like LAPACK exist. Fortran 90+ allows one
to write even more portable code using the KIND mechanism and the
selected_int_kind and selected_real_kind functions, which let you
specify the ranges of basic data types.

> Now, about the terseness and expressiveness?

Fortran 90/95 is more expressive than Fortran 77 in many ways, as
described in (for example) pages 7-8 of the essay "Numerical Recipes:
Does This Paradigm Have a Future?", available at
http://www.nr.com/CiP97.pdf . Quoting that paper:

"This, for us, was the revelation of parallel programming in Fortran
90.
The use of parallel and higher-level constructions -- wholly
independently of whether they are executed on tomorrow's parallel
machines or today's ordinary workstations -- expresses more science per
line of code and per programming workday. Based on our own experience,
we think that productivity, or achievable complexity of project, is
increased a factor of 2 or 3 in going from Fortran 77 to Fortran 90 --
if one makes the investment of mastering Fortran 90's higher level
constructs."

> > For scientific computation, consider the case of Numeric
> > and Numarray.
>
> I'm not happy with these, because they either make temporary arrays
> with wild abandon

Some early Fortran 90 compilers did this but have improved
significantly in this respect.

> or enforce an unnatural style of expression.

I wonder what this means.

<snip>

> I do not suggest that Python is currently competitive with C++ or
> Fortran. I simply agree with
> http://www.fortranstatement.com that something new ought to be
> designed, that a backward compatible Fortran2003 cannot possibly be
it,
> and that attention to fortran diverts resources from [the sort] of
> genuine progress that ought to be possible.

You have not given specifics about what "genuine progress" in a
scientific programming language would be.

<snip>

> Performance portability has nothing to do with what I'm talking
about.
>
> The answer belies the attitude that programmers are there to put in
> time and expend effort, because the only resource worth considering
is
> production cycles on a big machine.

Nonsense. Fortran was originally created to make PROGRAMMERS more
efficient by letting them code algebraic expressions instead of machine
code.

> This attitude explains why working with Fortran is so unpleasant an
> experience for anyone who has been exposed to other languages.

"Anyone"? Since I have been exposed to Python and C++ and still find
Fortran 90+ enjoyable, your statement is demonstrably false. Have you
ever used a version of Fortran past F77? The free Fortran 95 compiler
called g95 http://www.g95.org is available.

<snip>

> Getting a python package working usually amounts to an install
command
> to the OS and an import command to the interpreter. Then you can get
> down to work. Getting a Fortran package working involves not only an
> endless dance with obscure compiler flags and library links, but then
a
> set of workarounds for codes that produce expected results on one
> compiler and compile failures or even different results on another.

If one writes standard-conforming code it does not. At least with
Fortran one has multiple independent implementations of an ISO
standardized language, about 10 each on Intel Windows or Linux, and 4
for Mac OS X. Links are at
http://dmoz.org/Computers/Programming/Languages/Fortran/Compilers/ . If
one Fortran compiler leaks memory when multiplying matrices, one can
use another. If Python Numarray does, the only alternative I know of is
Numeric, which is no longer supported according to
http://www.pfdubois.com/numpy/ . I have found it extremely useful to
work with multiple compilers and compiler options. A good compiler such
as Lahey/Fujitsu has debugging options that aid programmer productivity
by finding bugs, both at compile and run time, at some cost in speed. I
gave a few examples in a previous thread. The existence of such
compilers refutes your assertion that Fortran programmers think only
machine time is important.