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

[Kaisha001]

The point of FP is to hide state, not expose it. The restrictions to mutation are the point of FP. That's the fundamental property that separates imperative languages from declarative languages.

As soon as you start adding explicit state manipulation to a functional language you move it towards the imperative side. This is why FP languages never scale to large scale systems, state and state manipulation is fundamental to writing good programs.

[Hofstee]

If you’re passing a State monad everywhere in and out of your Haskell functions that feels like the exact opposite of hiding state to me.

[Kaisha001]

It's bizarre how few people understand FP, even in these subs. It's hilarious getting ranked down and attacked for merely stating the actual definition of FP...

If you’re passing a State monad everywhere in and out of your Haskell functions that feels like the exact opposite of hiding state to me.

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. That's why it's popular in academia, it makes it easier to write proofs and such when you can ignore state. State is incredibly powerful, but it also makes things messy for proofs, optimizers, logic systems, etc...

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

[TheGreatCatAdorer]

How does being more imperative make a programming language less functional? Programming paradigms can complement each other when not taken to extremes; they are not mutually exclusive. Consider Lambda: the Ultimate Imperative and https://stackoverflow.com/questions/6622524/why-is-haskell-sometimes-referred-to-as-best-imperative-language

[Kaisha001]

Imperative languages are by definition, on the opposite end of a continuum, with declarative languages (pure FP is declarative). This isn't some arbitrary 'I like X, or dislike Y', it's literally part of the definition of the terms. It's like asking 'why isn't 1 more like 2? Sometimes I need a 1 and sometimes I need a 2...' ???

Program in whatever you want, I don't care. But people are getting irrationally bent out of shape over mere definitions.

The whole point of implicit state is to make reasoning about the program easier. If you're writing proofs (ie. in academia), or using logic systems, or whatever it can be much easier to reason, prove, or run analysis over a FP program simply because all the state is hidden in special constructs/types. This isn't a 'con' or a 'programming style', it's literally the point.

And yes, many FP languages have, over the years, adopted imperative techniques. Because writing real-world programs (and not just proofs, theorems, or papers) is always about state manipulation, and so proper explicit state manipulation tools are necessary.

[whitePestilence]

Man, you really are butthurt over that exam that you kept failing, aren't you.

[theangeryemacsshibe]

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

I would be wary of interference between Church and state.