declarations summary

[Michael Tobis]

Well, many scientists and engineers don't have the time, motivation or
ability to master the intricacies of recent fortran vintages either.
That's the problem.

Very large codes written by teams of software engineers for
well-delimited application spaces will continue to be written in some
version of Fortran. I hope the follwoing will explain why this causes
me difficulty.

Toy codes will probably move from Matlab to Python soon enough, if only
because Python, iPython and Matplotlib are free. It's the middle
ground, large codes as modified by single researchers, where much of
the real work of research gets done, and the infrastructure for this
use case is abysmal.

The near-term solution I'm coming to is code generation. As much as
possible I intend to present a clean Python interface to the scientist
and generate efficient compilable code behind their back.

Among the questions I'm trying to address is whether Python can or will
ever be so efficient that much of my work in this direction will be
abandoned. In that case, I can focus on the expression side, and leave
the efficiency question alone in the expectation that PyPy (or
something) will take care of it someday.

Another question is which language I should use as the back end. C or
even F77 can be coupled into the interactive environment on the fly.
Actual production work, of course, gains nothing from interactivity,
but we are still envisioning a significant scientist/developer use
case; in fact, that's the point.

Whether I like it or not, the group I work with is interested in is in
F90 source. (CCSM) This has proven awkward to integrate into Python,
though not impossible for some compilers thanks to the work of the
Babel and Chasm groups.

In practice, had the professional coders developing CCSM used C++
rather than Fortran90 (or even had they stuck to F77), we would be in a
better position to expose a well-defined low-complexity high-efficiency
layer to the non-CS specialist physical scientist. That's a mouthful, I
admit, but (trust me) the world would be a better place if it were
done.

So such advantages as do exist for a professional full-time
computational science group in developing CCSM in F90 have ended up as
a hindrance to what my constituency regards as the most important use
case.

Beliavsky's summary of what is available is a taxonomy of distinct
islands of production with tenuous connections between them. I don't
want quick-code slow-run "alternatives" to slow-code high-performance
production codes. I want, and my users need, a unified scientific
software environment which provides powerful expression without
sacrificing performance or interoperability.

Do I expect Fortran to go away? Not anytime soon. Do I expect an
alternative to emerge? Indeed I do, and I hope to be part of said
emergence. In fact, I don't know what the high-performance scientific
computer language of the year 2020 will look like, but I, for one,
would like it to be called "Python".

mt