5 ms·
Correct. Though many languages don't encourage and as a result don't have nearly as many pure functions as Haskell code.
by codygman 12y ago
Correct. Though many languages don't encourage and as a result don't have nearly as many pure functions as Haskell code.
- guscost 12y agoIn fairness, I could also say that hammers don't encourage carpentry best practices and as a result they cause many more smashed fingers than wood glue. The fact that a tool doesn't prevent counterproductive usage patterns doesn't automatically make it inappropriate for every job.
- jbooth 12y agoPoint being, I/O doesn't square with that concept. For some reason, every time I point this out, I'm accused of not appreciating the beauty of pure functions. I love pure functions. Maybe they're not appreciating the ugly reality of I/O?
- dragonwriter 12y ago> Point being, I/O doesn't square with that concept. Sure it does, and composes well under it.
- jbooth 12y agoI'm seeing I/O as "side effects with possible random error conditions". I really don't see how that squares with functional purity. It's late on EST but I promise if you put effort into explaining a higher-order take on this I'll put effort into reading and understanding it tomorrow. Have a good night.
- codygman 12y agoThrough monads functional purity with I/O is achieved, ergo you can compose I/O and get other advantages of purity.
- codygman 12y agoHow much experience do you have composing I/O in Haskell to prove that I/O doesn't square with that concept? Others here have experience using Haskell with I/O, but you just seem to have a hypothesis without experience or examples to support it.