I didn't try to imply that it was difficult to find the performance problem. It's an observation on something else: Haskell is often mentioned for its equational reasoning. I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance.
It'd be interesting to think how one could encode performance characteristics into equations.
I think having simple and direct denotational semantics necessarily means having relatively complex, indirect operational semantics (e.g: Haskell). Having a simple and direct operational semantics necessarily means having complex and indirect denotational semantics (e.g: C).
C makes performance easy and correctness hard.
Haskell makes correctness easy and performance hard.
The trick is, in most programs, you only need performance for a tiny subset of the program. You need correctness throughout the whole program.
Comments
I didn't try to imply that it was difficult to find the performance problem. It's an observation on something else: Haskell is often mentioned for its equational reasoning. I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance.
It'd be interesting to think how one could encode performance characteristics into equations.
I think having simple and direct denotational semantics necessarily means having relatively complex, indirect operational semantics (e.g: Haskell). Having a simple and direct operational semantics necessarily means having complex and indirect denotational semantics (e.g: C).
C makes performance easy and correctness hard. Haskell makes correctness easy and performance hard.
The trick is, in most programs, you only need performance for a tiny subset of the program. You need correctness throughout the whole program.
Why do you think that there must be a tradeoff between simplicity of denotational and operational semantics?
Because operational semantics (of contemporary computers, at least) are very different from a simple denotational semantics.
We have to bridge that gap:
1) Either use a compiler that hides away the operational details
2) Or use a language that directly maps to the operational semantics, but then is necessarily far away from the denotational ones
Its known that postpending to a linked list is slow. It's just a property of the data type.
That's not really an interesting property of Haskell, though. You can always write correct but slow code in any language.
I've seen the concept of encoding performance in types played around with, but I can't find actual work (if any) that's been done on it.
Yes, but Haskell makes that exceptionally easy.