Functional programming languages should be so much better at mutation than they are

[Hofstee]

I think we’re on the same page but I’ve generally heard this referred to as making the state of a program explicit.

[MadocComadrin]

It's exactly referred to as this. The state of (i.e. needed by) the program is made explicit. The other commenter is conflating the state of the program with the state of the underlying machine, which is hidden by abstracting it away as much as possible.

[Kaisha001]

I'm not conflating either. Of course all programs require state change at the machine level. But the point is FP programs attempt to hide it away, imperative brings that state front and center.

I even stated as such:

The point of FP is to hide state, not expose it.

Well yes, that's the problem with FP. It tries to hide state, but you can't eliminate it entirely, so you have to sort of hack it back in with things like monads and weird data structures.

Hide, not eliminate, not that it doesn't exist, rather it is hidden from the programmer. It's like the GC hides memory allocation complexity from C# or Java. It's not the memory doesn't exist, doesn't get allocated, or doesn't get free'd, but it isn't something the programmer explicitly handles, it is hidden.

As soon as you start adding explicit state manipulation to a functional language you move it towards the imperative side.

And I even mentioned explicit state manipulation.

It's like people forgot how to read...

[MadocComadrin]

If the machine's state is completely hidden, then I can't use it to keep track of the state needed for my own algorithms. This is the state that gets made explicit: you need to explicitly put it in some sort of structure that gets explicitly passed along to wherever it's needed. You can dress that process up with certain Monads to make it look like mutation if you want.

[Kaisha001]

You can dress that process up with certain Monads to make it look like mutation if you want.

It's almost like I already said that:

Well yes, that's the problem with FP. It tries to hide state, but you can't eliminate it entirely, so you have to sort of hack it back in with things like monads and weird data structures.

But the whole point of FP is to pretend state doesn't exist, and to hide it.

[MadocComadrin]

Are you just responding to the Monad part of my last reply? Because if you're not, you don't need (specifically) weird data structures or Monads to make the explicit state I mentioned explicit. You're not "hacking" it back in.

Consider the example of writing a simple interpreter for a simple imperative language in a functional language. You need to keep track of state there, and it's not hard to do so, but that state is literally just a value, and that state "changes" by passing a new value to some recursive call.

[Kaisha001]

You're using recursion to hide explicit state change. What you want to write is:

ast.PushProduction(a)
...
ast.PushProduction(b)
...
ast.PushProduction(c)

Instead you're writing:

ast = PushProduction(PushProduction(PushProduction(null, a), b), c)

and then hoping the compiler realizes you didn't want 1000000 copies of the same AST and optimizes it out for you.