[Haskell-cafe] Reasoning about performance

[Joachim Durchholz]

Am 05.12.2015 um 02:01 schrieb Dimitri DeFigueiredo:
> Indeed. I find laziness and the non-composable nature of space
> complexity in Haskell to be a much harder beast to deal with than
> immutability.

I can imagine. Immutability can be dealt with by applying a few 
principles in the key points, and everything will work out; space 
complexity is riddled with exceptions.
OTOH space and time complexity are non-composable (well, not trivially 
composable anyway) even in a strict language. As software grows larger, 
people start doing all kinds of deferred evaluation strategies, and the 
problems crop up - with the added complication that the software is 
already so large that the root cause of some complexity problem is 
hidden behind lots of tiny details.

So, I currently believe that Haskell is just showcasing the problem 
early. This is worth something, but I guess not for that majority of 
programmers who're doing business logic for websites, or for those just 
learning to code in Haskell and tripping over space complexity.

> There is an *excellent* introduction to the basics of lazy evaluation in
> Graham Hutton's book /Programming in Haskell/ (chapter 12), but I don't
> know of any good references beyond that basic level. Let us know if you
> find some!

Sumit gave a link to backhands.com which has turned out to be pretty 
deep and accessible.
Unfortunately, that link still does not offer a systematic approach to 
keeping tabs about complexity.

So... the main question is still open.
I hope somebody can shed insight about how to attack this. What do 
people do if they find their Haskell code to perform badly - do they all 
resort to ad-hockery, or is there a systematic approach that will either 
give insight what to change where? Even an approach that may fail is 
better than just ad hoc I think, as long as it succeeds often enough to 
be useful.

Regards,
Jo