Haskell vs. Clean

Simon L Peyton Jones simonpj@dcs.gla.ac.uk
Mon, 05 Jan 98 16:16:27 +0000


Ana

Further to Phil Wadler's comments:

> I am new in the functional programming world. I learned the trade from a
> book written by you. The first language I tried was Haskel (GHC). I
> found it large to download, difficult to use, difficult to install and
> slow. It requires a C compiler, and I wanted functional programming to
> get away from C. I need to qualify the word slow. I work with signal
> processing for natural language analysis, and this requires a lot of
> number crunching (systems of linear equations, wavlets, FFT, etc), and
> symbolic processing. My programs in Haskel turned out to be 10 times
> slower than the programs in C. Besides this, I was forced to use much
> smaller samples. I suppose that a person which knows Haskel well would
> do a much better job than I did. A Haskel programmer would use
> strictness analysis and things like that.

GHC is certainly hard to install on PCs.  The main reason for that
is that we're dead keen to support it on Unix as well, and I don't know
any way to make that compatible with easy installation on PCs.  In
particular, it's possible to make a PC look much like Unix via the Cygnus
tools, but that makes it a bit of a nuisance to install for PC people.
If anyone listening in to this knows a better way, pls tell me!

GHC does a much less good job on arrays than Clean does.  Generally that's
because we have regarded the numerical scientific computing area as too high a
hill to climb -- you have to be terribly good to really compete with Fortran.
But obviously there's a class of users (such as yourself) for whom performance
at least comparable with C makes a significant difference. It is something I do
plan to do something about. For example, I'd like to add strict, unboxed arrays
(and I can see how to do it, based on the Clean experience).

I do have one other suggestion: if your program is based around
incremental updates to arrays (lots of uses of "//")
then you will get really rotten performance in Haskell, but (if you
use the uniqueness types) decent performance in Clean.  Haskell
strongly encourages the use of array comprehensions, which work
well for most algorithms (though perhaps not yours).  I don't know
if this was the case, but if so it would certainly account for a large
fraction of the performance difference.  Programming array algorithms
using comprehensions is a rather different style to programming them in
C.

In short, I don't disagree with your conclusion, and it is
greatly to the credit of the Clean team that they have built such
a slick implementation, but it's an implementation (rather than
a language issue).  There are just so many hours in the day!

Good luck with your applications.  As Phil says, do please write
them up for the real-world applications page.

Simon