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_organi...) * 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-pro... * 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 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