[jdiez17]

You can use the Either monad to figure out where the computation failed and give meaningful errors. Or the Writer monad, to add logging to the computation.

Being able to resume the computation is possible, due to referential transparency - if you're able to serialise the monad and persist it to a file, you should be able to resume any computation at an arbitrary point in time. The Cont monad might also help in this case, but I've never used it myself: https://hackage.haskell.org/package/mtl-2.0.1.0/docs/Control...

Also, you can use monads to keep track of state in a functional manner - take a look at the State and ST monads.

What I'm trying to say is that you've indeed identified some of the sore aspects of functional programming, but these problems are not inherent to the programming model - they're all solvable in theory, with enough time and effort. It's a different paradigm, so some wheels have to be reinvented or adapted to it.

I agree with your last paragraph: stateful user interfaces are fundamentally better for us humans. Indeed, I think that mixing both imperative and functional programming is the way to go - have a stateful/imperative "chassis" around your functional "engine" and get the benefits from both.

[SilasX]

It sounds like you're saying those things are not an inherent limit of the pure functional programming model, and support it by listing ways to fix it that break the functional purity.

[jberryman]

> and support it by listing ways to fix it that break the functional purity.

I don't see anything in his post that does anything of the sort. Can you be more specific?

[gamegoblin]

The only way you're breaking functional purity is by doing IO, which none of those suggestions are doing.

[jberryman]

The point of `IO` is that using it doesn't break referential transparency.

[SilasX]

Several of them write to a file or store state in one. That's impurity, even if done "nicely".

It just feels like saying "don't talk to the outside world that way, do it this way".

[jdiez17]

The only part where I suggested to store a monad in a file is when I proposed it as a way of pausing a computation and resuming its execution at a later point in time. My mistake for mentioning the word "file", but I meant it in the abstract sense.