Coding style article with interesting section on white space

[Michael Tobis]

beliavsky at aol.com wrote:
> 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.

The reply "C++ is even worse", while debatable either way, seems to be
a common response from Fortran defenders. It misses the point.

What the scientific community needs, whether they know it or not, is
high-performance Python if that's possible, or something as close to it
as possible. Specifically, something with serious introspective power
and economy of expression.

> > I prefer my languages to be portable, terse and expressive.
>
> 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.

Now, about the terseness and expressiveness?

> 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, or enforce an unnatural style of expression. I could
see how they would be useful to others but they are awkward in
long-time spatially coarse finite difference/finite volume/spectral
calculations, which is the problem space I care about.

As for non-coarse (finite element) integrations (where rectangular
decompositions do not suffice) it seems to me that using Fortran is
sheer madness, even though there are real pointers now.

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 teh osrt of
genuine progress that ought to be possible.

> 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.

Without disagreeing with Alex Martelli's response to this, I find it
nonsensical on other grounds.

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. This attitude explains why working
with Fortran is so unpleasant an experience for anyone who has been
exposed to other languages.

An alternative attitude is that the amount of human effort put into
solving a problem is a relevant factor.

In this view, "portability" is actually about build effort, not runtime
performance. Perhaps the Fortran community finds this idea surprising?

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.

The day when project cost was dominated by machine time as opposed to
programmer time is coming to a close. Fortran is a meaningful solution
only to the extent that programmer time is not just secondary but
actually negligible as a cost.

The assumption that portability is somehow about performance belies
total lack of concern for the programmer as a resource, and therefore
to the time-to-solution of any new class of scientific problem. The
result of this habit of thought (entirely appropriate to 1955) is that
in an environment where fortran is expected, new problems are
interpreted as changes to old problems, and the packages become vast
and bloated.

Since most of these legacy codes in practice predate any concept of
design-for-test, they are also almost certainly wrong, in the sense
that they are unlikely to implement the mathematics they purport to
implement. Usually they are "close enough" for some purposes, but it's
impossible to delimit what purposes are inside or outside the range of
application.

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

They aren't helping either, for the most part.

Psyco aside, institutions that ought to be supporting development of
high-performance high-expressiveness scientific languages are not doing
so.

Institutions with a Fortran legacy base are confused between
maintaining the existing investment and expanding it. The former is
frequently a mistake already, but the latter is a mistake almost
always. This mistake drives investment of effort in inefficient
directions, where efficiency is about design and build cost-to-solution
rather than runtime cost-of-execution.

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

Er, replaced the modest C interoperability they lost in F90, right?

The codes I care about aren't new ones. So now I have to hack into the
code and redeclare all my arrays, right? So that they'll have a defined
structure? And hope that doesn't break some other assumptions? Except
that I have to await someone actually releasing an F03 compiler, right?


Thanks. It turns out that I need a compiler, not a specification,
unfortunately.

Even so, I understood that there was some resistance to even this level
of interoperability, because it breaks the Fortran no-convention
convention. C-interop vapor-mode will require, (oh horror!) a
specification for which bytes represent what. Now each vendor will have
to try to patch that back in to their idiosyncratic representation.
They'll probably get it mostly right, eventually.

> > Python fundamentally respects the programmer.
>
> What does that mean?
>

If you don't know by now, don't mess with it.

mt