[Haskell-cafe] Haskell Propaganda needed

[Don Stewart]

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 <victorsmiller at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>