One sentence in the article made me do a double take: "reasonably tightly optimized low-level Haskell". For I minute I thought that this defeats the whole purpose of using Haskell, because for me it's all about being able to code at a higher level of abstraction.
But when I saw how quickly he fixed the problem, I reconsidered. As wrong as low-level tweaking in a high-level language feels, if it's still less work to optimize than in C or Java, that's a win, right?
I think of programming in Haskell as being more about being able to choose a level of abstraction that makes sense for the situation.
The more abstract code is great when it works well, and when it falters I can easily drop down to something more concrete, or even to C, and still have most of my code benefit from that higher level of thinking.
Someone with more experience can correct me, but "low-level Haskell" is Haskell that takes into consideration things like evaluation order and thunks. It is stuff that many other languages would still consider way-high-level.
But when I saw how quickly he fixed the problem, I reconsidered. As wrong as low-level tweaking in a high-level language feels, if it's still less work to optimize than in C or Java, that's a win, right?