[tenfingers]

It's worth nothing that functional programming is hard not because of the functional paradigm, but due to the constraints you have while solving a problem (memory, for one).

This requires changing the simple, composable functions that you could reuse forever, to complex ones that have to split the work into multiple stages.

Another source of inherent complexity which has nothing to do with the solution of the problem itself, is the handling of the input or runtime issues. Input cannot be guaranteed to be always coherent, and runtime issues may arise while running (user interrupt). At this point, interrupting the computation is easy, but as an user I want maybe:

* know why the function stopped, with a meaning answer (not just a stack trace)

* know the location of the error in the input data

* the possibility to resume the computation

If you've ever programmed functionally, you know how hard is to do something as simple as give meaningful error messages buried into a series of fold/map calls.

Keeping state is a simple (and I would say equally elegant) solution to this recurrent problem. Please consider that I'm saying this from a functional programming perspective (as in: objects as localized state containers not necessarily breaking the purity assumption).

Another issue is that we, as humans, are based on a stateful world. Stateful user interfaces are sometimes more efficient due to the way _we_ work. This can be seen in something as simple as "now select a file", which brings up a dedicated section of stateful code to navigate a tree. As such, you are constantly faced with the problem of keeping state.

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

[seanmcdirmid]

Amen. You might want to check out my project that attempts to rationalize mutation through time management rather than avoid it:

http://research.microsoft.com/en-us/people/smcdirm/managedti...

Anyways, there are many other ways of fixing or transcending Von nuemann, pure functional might not be it.

[hyperpape]

This is the second time I've looked at that page (saw it on LtU several months ago), and I find it baffling.

In particular, what escapes me is what those videos represent. Why are they showing typing, rather than what some code does? Are you demonstrating a programming language or a live coding environment? The first two paragraphs seem to discuss the former, but the videos look like the latter. And if it is the latter, I can't figure out what the language is doing because I'm so hung up on the typing/deletion/live feedback.

The only way I've been able to get anywhere is by looking at the paper. You might want to link to the paper or some other overview rather than this page.

[seanmcdirmid]

Both. It is a live programming (not coding) environment in the spirit of Bret Victor, but it is made possible by automatic time management. You can't really show that however, so the essay focuses on the programming environment making the benefits more tangible while the paper focuses on the programming model (I point people at the essay first because many don't want to read papers). The paper is linked at the top of the essay.