

The rise of Python in computational science - TriinT
http://www.walkingrandomly.com/?p=2062

======
danbmil99
> Can we stop promote imperative-ish languages and focus on where lambda can
> take us?

nope, and why would we? For many applications, including the majority of
scientific research, FP is a non-starter. You need a simple, robust,
procedural language that thinks the way most of our brains are wired. There is
no reason or payoff to wrapping your mind around an arcane style of
programming when the software project is not going to need the benefits of
that style of development.

~~~
xtho
How can you say FP was a non-starter? Just because some aging environments
were designed by Fortran hackers? FP is better suited for parallelization. And
where would you put R?

~~~
cdavid
(disclaimer, I am a Numpy/scipy dev)

I think the language is just part of it. I would go as far as saying that from
a purely "technical" POV, lisp and ML (e.g. OCAML) are superior languages to
python in almost every way. Nevertheless, I think those are, at least today,
not as good choices as python for scientific research, for at least two
reasons.

First, I strongly believe scientific work in general needs to be more open,
both publication-wise and implementation-wise. I see programming languages as
a communication tool as much as an implementation tool for science, and I
think python fills this very well, because it is very readable to the casual
programmer. LISP is too foreign for this audience. P. Norvig mentioned about
LISP relative failure for non CS scientists this at his talk for scipy09
(<http://www.archive.org/details/scipy09_day1_03-Peter_Norvig>) - and I think
you can count him as a LISP fan. To quote his talk, at some point, "you have
to stop fighting reality".

Secondly, there is something about the LISPs, haskell and OCAML communities
which do not pave well compared to python. Those are very CS-savies, really
oriented toward programming - which is fine. Different goals, different tools
and all that.

Also, do not forget that in science, projects generally last much longer than
in most other areas. That's one of the reason why Fortran is still so
pervasive, after all. It is also maintained by different people (grad
students, etc...), involving several generations in some cases. Having a
relatively mainstream language is a requirements - python is already too weird
in many cases...

Concerning parallelization: even if you assertion were true, that's a concern
only for a tiny proportion of what people do. Speed really does not matter
most of the time (but it is true that when it does, it often does it in a
significant way - high energy physics, climate modellization, etc...). I would
be cautious about FP being better for parallelization for scientific work,
though: a lot of tasks can be solved using MPI, etc... and correct me if I am
wrong, but I don't believe FP brings a lot of advantages there.

Recently, a perspective from W. Stein, who started the SAGE project, was
mentioned on LtU, and the article provides more insights, coming from a quite
different background: <http://lambda-the-ultimate.org/node/3712>

~~~
graphene
It's interesting that in Norvig's talk you linked, while praising python, he
also mentions that he is a supporter of the functional programming style for
scientific work, both because it more transparently mirrors the mathematical
formulation of the algorithm, and because it should make the use of massively
parallel computations easier. I concede that there are currently few
implementations of massively parallel, functional code (MapReduce and possibly
Data Parallel Haskell come to mind) and it's true that the MPI-based Single
Program, Multiple Data paradigm is dominant for now, the functional paradigm
being but a very promising newcomer.

Given that, and the fact that languages such as Lisp, Haskell and OCaml are
more aimed at the functional paradigm, wouldn't you agree that there is
possibly a general shift going on in scientific programming in general, from
Fortran/C(++) imperative style, via python, towards finally any of Haskell,
Lisp and/or OCaml?

I don't really agree with your implication that the (at first) obscure way of
doing things functionally makes the work less open, and that this makes it
less desirable. If everyone worked in exactly the same way, communication
would be easier, but there would never be any disruptive change. I think
letting everyone figure out for themselves what language works best for
his/her appliciation has more merits than trying to enforce a standard, be it
python + numpy & scipy, or anything else. If there turns out to be one clear
winner, people will gravitate to that automatically, but you shouldn't argue
for harmonization for its own sake.

~~~
chancho
> and because it should make the use of massively parallel computations
> easier. I concede that there are currently few implementations of massively
> parallel, functional code (MapReduce and possibly Data Parallel Haskell come
> to mind)

Not only are there few, their numbers are growing much more slowly than
traditional C/Fortan/MPI environments. The "massive" in massively parallel is
getting more and more massive every year. Running computations at full speed
at these scales, 100K+ cores in multiple levels of hierarchy (same die, same
board, same blade, same switch, etc) is a hugely mundane architectural
problem. Not only is there no architecture besides MPI which has nearly as
much effort invested in this problem, none are currently making the
investment, so none have a chance to catch up within the next decade. The only
way you will see FP doing massive parallelism at speeds even close to current
best is if they wrap the C MPI interface, and I have yet to see any functional
message-passing APIs which aren't tarted-up imperative environments. (If
anyone knows any please share.) At it's core, message passing programming
involves managing data, deciding where it resides and where it needs to go,
which is kind of antithetical to FP.

You mention MapReduce, which I think is more of a data-center thing subtly but
fundamentally different from HPC, involving less computation and more I/O. FP
has a good shot there (cf. Erlang) but not much chance at cracking the HPC
market.

~~~
graphene
_The only way you will see FP doing massive parallelism at speeds even close
to current best is if they wrap the C MPI interface, and I have yet to see any
functional message-passing APIs which aren't tarted-up imperative
environments_

True, I would not be surprised if it evolved that way, but according to my
(modest) knowlegde, it is possible for imperative routines to have a purely
functional interface. The extreme case of course is the fact that any
functional high-level code needs to be translated to assembly code to run at
all, but I don't see why that boundary can't be on a higher level; As long as
the developer programs functionally (and derives the benefits from that), does
it matter that his code is being translated first into imperative MPI-ified C,
and then assembly?

This is all provided, of course, that you can actually leverage the
parallelism-related benefits of FP this way, which I guess is not known as of
yet. You mentioned "functional message-passing APIs which [are] tarted-up
imperative environments", care to give an example? I'm intrigued...

As for MapReduce, of course it's different from what the average HPC machine
is used for, but being an embarrassingly parallel problem, it's one of the
first problems where the FP approach has been shown to work. In other (eg
typical HPC) applications, there's lots of work ahead in rethinking the
algorithms so they can be expressed functionally, before you can even begin
contemplating how to use the hardware.

------
morphir
why is python preferred above scheme or any other lisp, like clojure? Can we
stop promote imperative-ish languages and focus on where lambda can take us?

~~~
ubernostrum
Because Python mixes:

* Easy to learn (including a REPL),

* Multi-paradigm programming (doesn't shove a One True Way To Program(TM) down your throat), and, most important of all,

* Solid, battle-tested libraries for the domain (SciPy/NumPy/Sage/etc.) and an easy-to-use interface to/from C.

~~~
hyperbovine
Also, the code is extremely readable. I can't think of another language that
communicates the programmer's intent better than Python. People often write
code aesthetics off, but it really matters. When your audience includes not
just fellow programmers, but also potential collaborators, who may or may not
know Python, as well as your adviser, who knows only FORTRAN, having a
language that self-documents is helpful.

~~~
xtho
The French call it déformation professionelle, which works wonders when it
comes to perceiving the weirdest stuff as perfectly normal.

