Andre Pang writes (in the Haskell cafe):
The executive summary of my thoughts is that it seems to be entirely possible to optimise Haskell to be competitive with other, more performance-focused languages, but it's hard...
and from his blog:
if you need speed, you can get it in Clean much more easily in than Haskell.
Perhaps Clean gives your more fine-grained control over the memory and execution behaviour of your program, but this is normally at the expense of clarity and elegance of your program. This is where I think we (FP-ers) stand: We can write elegant programs and we can write efficient programs, but combining these two aspects is still difficult. The Haskell and Clean entries in the Language Shootout clearly demonstrate this. Here are some ideas to better combine elegance and efficiency - decouple data and functions It's often easy to make choices in the data structures with an eye to efficiency, for example sometimes it's better to unbox elements (faster access), sometimes it's better to share the elements (use less memory). The programmer should be able to make these decisions without changing the functions that use the data structure. Overloading can help, but perhaps a good implementation of views will improve it further. - more compiler optimisations Preferably the optimisations should be reasonably predictable for the programmer. - programmer guided transformations, optimisations I don't think we'll ever reach the state where compiler optimisations can completely bridge the gap between elegance and efficiency. I don't mind giving it some help, but I'd like to keep my original program. For example, tell the compiler to unfold a function once, so that the function is strict in more arguments in the recursion.
[In Clean] you can, for example, make an unboxed, strict array just by writing [# 1, 2, 3 !] rather than [1, 2, 3]
I call [# 1, 2, 3 !] a tail-strict list with unboxed elements (it doesn't have constant time access). Cheers, Ronny Wichers Schreur