Hey Victor, Thankfully, there's lots of material and experience reports available, along with code, for the Haskell+science use case.
In my view Haskell works well as a coordination language, for organizing computation at a high level, and thanks to its excellent compiler and runtime, also works well for a parallel, node-level computation. It is also fairly commonly used as a language for generating high performance kernels thanks to EDSL support. Thanks to the rather excellent foreign function interface, its also trivial to interact with C (or Fortran or C++) to do number crunching, or use other non-Haskell libraries. Another way to view it is the conciseness and ease of development of Python, with compiled, optimized code approaching C++ or C, but with excellent parallel tools and libraries in a class of their own. Some random links: * The Parallel Haskell Project - http://www.haskell.org/haskellwiki/Parallel_GHC_Project - an effort to build parallel Haskell systems in large-scale projects, across a range of industries. ( Six organizations participating currently, http://www.haskell.org/haskellwiki/Parallel_GHC_Project#Participating_organisations) * Parallel and Concurrent Programming in Haskell, a tutorial by Simon Marlow, http://community.haskell.org/~simonmar/par-tutorial.pdf * 11 reasons to use Haskell as a mathematician , http://blog.sigfpe.com/2006/01/eleven-reasons-to-use-haskell-as.html * Math libraries on Hackage, http://hackage.haskell.org/packages/archive/pkg-list.html#cat:math , including e.g. statically typed vector, cleverly optimized array packages, and many others. * a collection of links about parallel and concurrent Haskell, http://stackoverflow.com/questions/3063652/whats-the-status-of-multicore-programming-in-haskell/3063668#3063668 * anything on the well-typed blog, http://www.well-typed.com/blog/ It's important to note that many of the high performance or parallel-oriented libraries in Haskell use laziness or strictness very carefully. Sometimes strictness is necessary for controlling e.g. layout (see e.g. the Repa parallel arrays library: http://www.haskell.org/haskellwiki/Numeric_Haskell%3a_A_Repa_Tutorial) while sometimes laziness is essential (for minimizing work done in critical sections inside locks). Cheers, Don On Sat, Jan 14, 2012 at 5:33 PM, Victor Miller <victorsmil...@gmail.com> wrote: > I'm a research mathematician at a research institute with a bunch of other > mathematicians (a number of whom are also expert programmers). I recently > (starting three months ago) have been learning Haskell. I'm going to give a > talk to the staff about it. Most of the audience are pretty experienced > programmers in C/C+/Python, but with little or no exposure to functional > languages. I'm looking for talks from which I can cannibalize good selling > points. I was led to Haskell by a somewhat circuitous route: at our place, > as with most of the world, parallel programs (especially using GPUs) are > becoming more important. A little googling lead me a few interesting > projects on automatic mapping computations to GPUs, all of which were based > on Haskell. I feel that this will be the way to go. There's one guy on > the staff who's a demon programmer: if someone needs something to be adapted > to GPUs they go to him. Unfortunately I find reading his code rather > difficult -- it's rather baroque and opaque. Thus, I'd like something more > high level, and something amenable to optimization algorithms. > > In my former life I worked at IBM research on one of the leading edge > compiler optimization projects, and learned to appreciate the need for clear > semantics in programs, not just for developing correct programs, but also to > allow really aggressive optimizations to be performed. This is another > reason that I'm interested in functional languages. > > I know that I'll get peppered with questions about efficiency. We (our > staff) is interested in *very* large scale computations which must use the > resources as efficiently as possible. One of our staff members also opined > that he felt that a lazy language like Haskell wouldn't be acceptable, since > it was impossible (or extremely difficult) to predict the storage use of > such a program. > > So, any suggestions are welcome. > > Victor > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe