In 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.

Point 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?

How 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.

> Point being, I/O doesn't square with that concept.

Sure it does, and composes well under it.

I'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.

Through monads functional purity with I/O is achieved, ergo you can compose I/O and get other advantages of purity.