Ashley (ashley_y) wrote in declarative,

Haskell vs. OCaml

Haskell is my favourite language, but it's slow. In the Shootout, GHC-compiled Haskell performs poorly, while OCaml performs very well. Am I right in thinking laziness is to blame? Laziness is actually one of the less interesting things about Haskell in my view, I'm more interested in monads, type-classes, and other clever type stuff.

  • Post a new comment


    default userpic
I can't claim to be authoritative, but when I studied laziness in my compilers class, it seemed like there was really no good way to do it without a severe cost to performance. At the same time, though, since there are clear problems with normal order and applicative order evaluation, it seems lazy evaluation is somewhat of a necessary evil.
But isn't lazy evaluation the same as normal-order evaluation (usually with memoization)?

My, how things change. :)


August 3 2006, 05:56:00 UTC 10 years ago

My experience with Haskell has been the reverse.

How do you express control flow contructs without lazy evaluation? (or normal order)

How do you implement a purely functional applicative language without (some) lazy evaluation?

In some cases (or at least some of the weird programs that I write) it seems like lazy evaluation is more efficient than strict evaluation, but perhaps not as a general purpose evaluation strategy... but I am going to do some work of my own to find if this is true in practice. (and what's to stop you from embedding strict versions of primitives in haskell -- it's easy to do the reverse in scheme, so I would assume that strict primitives in haskell would be trivial)

It seems to me that monads are all about packing up thunks to be evaluated later, very cps like. I don't see how lazy evaluation wouldn't be interesting if you are interested in monads (or at least lambda expressions to wrap up code for later use anyway)

Interesting thoughts anyhow.
Since I wrote that, GHC's scores in the shootout have improved, and now it's considered fast.