Why python???

[Michael Peuser]

"Basile STARYNKEVITCH" <basile-news at starynkevitch.net>

> ASCI are big US government (DoE or DoD) supercomputers (used
> notably for nuclear weapons computations).
>
> However, contrarily to Michael's belief, it won't surprise me at all
> that some big numerical computations are driven by scripting languages
> (scripts which call big number crunching primitives coded in C or C++
> or Fortran). At least in Europe, several number crunching applications
> are driven by scripts. Of course, a huge fraction of the CPU time (ie
> >= 98%) is spend in numerical routines coded in Fortran or C. Only a
> tiny fraction of the work is spent in interpreting scripts.
>
> I don't know if the ASCI boxes are running numerical computations
> driven by Python (or Ruby) scripts, but obviously they could (and
> sometimes similar applications are designed around a scripting
> language).


This thought had occured to me too after posting  it, but I have no
information. One of the things that impressed me in Python was that it is
aware of complex numbers and it has NumPy (which in fact is *not* Python).
Though I think that this very rarely is stated as one of Python's
overwhelming assets and most people even wonder what this can be used for
;-)

But you bring up Python's aspects as a "glue language". Is Python the better
"glue language"? May be. Have look at DISLIN which (I think) is a FORTRAN
project by nature. And SIP and WSIG are quite nice.

However the *real* programs then are the mathematical packages, OpenGL,
simulation and visualisation.

But may be the whole concept of programming is changing somehow - not in the
direction of OOP; that is "by the way" so to speak. But to the following
understanding:
    A program is an entity that controls other entities by support of an
underlying virtual machine.

This new view will support the existing differentiation between package
maker ("real programmer") and scripting user ("domain specialist")

In this interpretation (as secondary glue language) I see a good future for
Python.

So we most of our time have to learn what this virtual machine does (in its
yearly upgrading versions) and how to interface the "other entities". When
looking through this NG most of the topics touch these issues. In the past
it would have been unthinkable to get your assemply program running without
the most detailled understanding of every machine instruction you used....
You might already have guessed, that I belong to the generation that learnt
programming the Knuthian way, starting with assembly language and beeing
always aware that a van Neumann hardware interpreted their compiled code.
And input and output were a teletype.....

Kindly
Michael P