I agree that keeping IO sequestered is generally good advice. And it's something that I also do in imperative and OO languages as a rule of thumb. But having th

I agree that keeping IO sequestered is generally good advice. And it's something that I also do in imperative and OO languages as a rule of thumb. But having the type system signalling at IO is happening doesn't end up being useful in non-lazy languages where purity doesn't actually help an optimizer. I found this blog post to be kind of interesting: https://blog.ploeh.dk/2017/02/02/dependency-rejection/ https://blog.ploeh.dk/2017/02/02/dependency-rejection/ Skim that and then take a look at the back-and-forth in the comments. Sometimes going out of your way to write mostly pure (or just non-IO) functions can make your code more difficult to reason about. In my experience, you're sometimes left with two choices: either do a bunch of IO upfront that you might end up throwing away (if there is an `if` statement in your pure function that determines whether you need the result of some IO op), or pull out logic into the naughty impure edge of your program. If you do the former, you're wasting performance. If you do the latter, you're not actually fixing anything that pure functions are supposed to help you with, because you still have logic in impure functions. In my experience there are these edge cases where finding the cutoff between "the edge where I'm allowed to do IO" and the "pure business logic" is not that clear or easy. Also, as the old saying goes: monads don't compose well.