Being lazy evaluated, Haskell, makes it hard to reason about performance in more than trivial code (as a rubik cube solver would be).

All those suspended computations may eat your RAM for no good reason at all. For example:

    sum (replicate n 0)

has a space leak O(n). While:

    foldl' (+) 0 (replicate n 0)

works fine O(1) space wise.

My point is that it is easy to eat all your RAM using haskell even in the simple `sum` case above. More so in more involved computations.

Of course, if you can compute your solution in constant space using C, you can also do it in haskell. But writing it in Haskell would require careful thought in how your code is evaluated.

EDIT: It is about trade offs.

If you want declarative and readabe code, with little memory layout noise (allocate memory, assign variables, etc...) then haskell is a reasonable choise. You can write fairly readable clode for complex algorithms. If you are an expert, you can also make it efficient on the first go (speed and space wise). If speed is of upmost importance, then you can write more compiler specific code but with a lot of added noise.

Or you can start with C, write less (than haskell) declarative code and less readable code. It would be harder to get right(the more complex the computation the harder to debug), but when you are done you probably have efficent code. If you have the experience, you may be able to make it fairly readable too.