4 ms·

What about the performance challenges caused by lazy evaluation?

belmont_sup 4y ago
Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure. In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files. Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages. slow = let files = mapM makeAndReadFile [1..500] :: IO [ String ] in files >>= (putStrLn . show) Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand. safe :: IO () safe = foldl ( \ io id -> io >> makeAndShow id ) (return ()) [1..500]
wyager 4y ago
People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)
- abathologist 4y ago
  That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?
  - wyager 4y ago
    It's not that space leaks are not a concern; it's that it's actually quite easy to avoid creating them, and if you manage to do so and it becomes a problem, it's usually easy to track down. I don't know any experienced haskell programmer who would even mention this in a list of complaints about the language (which they are sure to have, but they will likely be more abstract).
marcosdumay 4y ago
Most people don't even get to see those challenges. But make wide use of the many performance opportunities created by lazy evaluation. Anyway, when any problem appears, it is obvious, so if it was a large problem, it would be fixed by now. The only reason people keep talking about it is because it nearly never appears. Really, lazy IO is a much larger source of problems, and even there, after a week or two writing IO people just learn to write code that doesn't break due to it.

Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure. In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files. Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages. slow = let files = mapM makeAndReadFile [1..500] :: IO [ String ] in files >>= (putStrLn . show) Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand. safe :: IO () safe = foldl ( \ io id -> io >> makeAndShow id ) (return ()) [1..500]

wyager 4y ago

People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)

abathologist 4y ago
That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?
- wyager 4y ago
  It's not that space leaks are not a concern; it's that it's actually quite easy to avoid creating them, and if you manage to do so and it becomes a problem, it's usually easy to track down. I don't know any experienced haskell programmer who would even mention this in a list of complaints about the language (which they are sure to have, but they will likely be more abstract).

marcosdumay 4y ago

Most people don't even get to see those challenges. But make wide use of the many performance opportunities created by lazy evaluation. Anyway, when any problem appears, it is obvious, so if it was a large problem, it would be fixed by now. The only reason people keep talking about it is because it nearly never appears. Really, lazy IO is a much larger source of problems, and even there, after a week or two writing IO people just learn to write code that doesn't break due to it.