6 ms·

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

by xtho 17y ago

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 17y ago
(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 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 http://lambda-the-ultimate.org/node/3712
- est 17y ago
  I hate to say this, but Python == VB for science.
  - jpr 17y ago
    That would be funny if it wasn't so insulting for modern VB. Python is the oldschool BASIC for science.
- graphene 17y ago
  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 17y ago
    > 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.

by xtho 17y ago

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 17y ago

(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 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 http://lambda-the-ultimate.org/node/3712

est 17y ago
I hate to say this, but Python == VB for science.
- jpr 17y ago
  That would be funny if it wasn't so insulting for modern VB. Python is the oldschool BASIC for science.
graphene 17y ago
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 17y ago
  > 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.