Hi,

Van's response to the "RETIRE FORTRAN" also contains a number
of distortions and exaggerations, though in a direction opposite
of that of the original authors.  Here are a few.

On Fri, 20 Feb 2004, 8:12am -0600, [log in to unmask] wrote:
> Sender:         [log in to unmask]

> Item 1 is wrong: The Fortran 95 standard is 386 pages, not 700 pages.
> The C99 standard is 556 pages.

> If you're talking about textbooks, consider that the most
> frequently-recommended Fortran 95 textbook, "Fortran 90/95 Explained," is
> 392 pages.  "Teach yourself C++ Programming in 21 Days" is 814 pages.

Kernighan and Ritchie is 272 pp.  You can find far longer Fortran
texts than M&R, and you can find far longer C texts than K&R,
but it seems to me that K&R and M&R are pitched at similar levels
for their respective languages.  (They are both favorite books
of mine, by the way.)

> Item 7 is a half truth, and most of the disadvantages cited are actually
> advantages.  Fortran does have an official preprocessor: ISO/IEC 1539-3
> -- but it doesn't do macros, so Item 7 has a grain of truth in it.  In
> any case, it's not common to really really need a preprocessor because
> Fortran programs are inherently more portable than C programs.  Most
> "portable" C and C++ programs consist almost entirely of preprocessor
> macros and ifdef's.  I have a 300,000 line Fortran 95 program that runs
> on several platforms, and it doesn't have even one preprocessor directive
> anywhere.

I've never seen a large Fortran program that doesn't require
some services that the language doesn't provide but that
are provided by OS calls instead.  Bindings are usually provided
in C.  Thus, must Fortran programs must call C, and the way
this is done of course differs from platform to platform.

In addition, the OS calls differ from platform to platform,
so there may be #ifdefs in the C code.  But these involve
funtionalities that neither C nor Fortran supplies directly
by dint of the language definition, so it's neither here
nor there.

I've literally never seen any large (or even small) C programs
that "consist almost entirely of macros and ifdefs."  Also,
many -- probably most -- macros are programming-convenience macros
which have no platform dependence.

Van and I may have seen different Fortran programs (since
his don't seem to have to call C) and different C programs
(since his seem highly platform-dependent).  I'm curious
where the platform-dependence arises, outside of OS
calls, though.

C++ is a different story;  C++ has only recently been
standardized, and standard-conforming compilers are still
not as ubiquitous as for Fortran or C.  Hence #ifdefs.

I'm curious how Van handles platform-variation of KIND
parameters (assuming he needs to do this).

> ...Sure, C
> processors check references to functions against their prototypes, but
> the prototype is separate from the function body; I don't know of any C
> processor that checks prototypes against function bodies.

I've never seen one that doesn't.  If you have a prototype in
a .h file, and that .h file is visible in the .c file where
the function is defined, I get a function/prototype mismatch.

Maybe "never seen" is an exaggeration, and I've not done
a broad survey;  but I just checked on IRIX and AIX, using
the native C compilers, and on Linux with gcc, and all of
these flag the mismatch explicitly.

> Although item 9 is sort-of true (Fortran 77 programs are frequently
> faster than equivalent Fortran 90 programs), it's also misleading;
> Fortran 95 programs are usually a bit faster than equivalent C programs,

I have never seen more implementation-to-implementation variation
in performance than I have seen in F95 performance relative to
F77 performance when F95 syntax is used.  I've spent days trying
trying to find constructs that will work reasonably well on
all machines.  And these were all UNIX!  At times, I've reverted
to old F77-style do-loops, instead of array notation, to get
things to work reasonably well across the board.

The point is that (as I've heard is the case in C++ as well)
it takes a great deal of understanding of what is really going
on under the hood to avoid shooting yourself in the foot.

There are some things like this even in F77;  for instance,
programmers know that when traversing a 2D array using
nested DO-loops, the row index should vary in the inner loop.
There are many more things like this to be aware of in F95,
and some of them are rather subtle.

-P.