Coding style article with interesting section on white space

[beliavsky at aol.com]

Michael Tobis wrote:
> (unwisely taking the bait...)
>
> If you like your language to look like this
> http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html
> then more power to you.

Thanks for pointing out that interesting article on Fortran 90 bugs.
How long would a comparable C++ list be? Even Python has gotchas, for
example the difference between deep and shallow copies.

> I prefer my languages to be portable, terse and expressive.

Fortran programmers are generally happy with the portability of the
language. A difficulty with Python portability and maintainability is
that some needed functionality is not in the core language but in C
extensions. For scientific computation, consider the case of Numeric
and Numarray. I don't think Numeric binaries are available for Python
2.4, and Numarray is not perfect substitute, being considerably slower
for small arrays, having slightly different functionality in some
areas, and
as recently as Nov 2004 (c.l.py thread "numarray memory leak") leaking
memory when multiplying matrices.

The recent "Pystone Benchmark" message says that Python is only 75% as
fast on Linux as on Windows. Fortran programs do not suffer this
performance hit and are in this respect more portable. In theory, as
has been mentioned, one could use a faster compiler to compile CPython
on Linux, but AFAIK this has not yet been done.

<snip>

> There is no fundamental reason why a language with expressive power
> much like Python's cannot have run-time performance comparable to
> Fortran's. Unfortunately, Fortran's dominance of the relatively small
> scientific computation universe has prevented such a language from
> emerging.

Nobody is stopping Python developers from working on projects like
Psyco.

> The solutions which interest me in the short run are 1)
> writing a code generation layer from Python to a compiled language
> (possibly F77 though I will try to get away with C) and 2) wrapping
> legacy Fortran in Python. The latter is quite regularly subverted by
> non-standard binary data structures across compilers and a pretty
> profound disinterest in interoperability by the people designing the
> Fortran standard that makes their interest look more like turf
> protection and less like an interest in the progress of science.

So uninterested in interoperability is the Fortran standards committee
that they added interoperability with C in Fortran 2003 standard.

<snip>

> Python fundamentally respects the programmer.

What does that mean?

> Fortran started from a point of respecting only the machine, (which
is > why Fortrans up to F77, having a well-defined objective, were
> reasonable)

I have found that Fortran 90/95 is better at the objective of FORmula
TRANslation for array expressions (mostly what I need) than previous
versions.

> but now it is a motley collection of half-baked and
> confusing compromises between runtime performance, backward
> compatibility,  and awkward efforts at keeping up with trends in
> computer languages.

This is true to some extent of any language "of a certain age",
including C++.

<snip>

> For more see http://www.fortranstatement.com

And the rebuttal at http://www.fortranstatement.com/Site/responses.html
.