[phizy]

Mathematicians have no trouble modeling change. There are many ways to do so. Some are algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all.

Either way, it is unclear what you're actually trying to say. Haskell has methods for modelling change of state through pure objects, but you're talking about that as though it were an inherently flawed or invalid approach, rather than one of many equally valid approaches to modelling state transformations.

[nerdtime]

>but you're talking about that as though it were an inherently flawed or invalid approach,

This is just your bias. I never said this. I feel some people worship a paradigm so much that they see everything as an attack. FP is great however it is not a one size fits all solution. There are limitations. This is literally what I said.

>Mathematicians have no trouble modeling change. There are many ways to do so. Some are algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all.

You can model change with purity but the program in the end actually has to conduct the change without the modelling. The application has to eventually perform real world actions and the purity of your program cannot protect you from potentials pitfalls of imperative style errors/mistakes.

You have a database. The purity of haskell does not remove the necessity of mutating data in that database.

What you can do is segregate dealing with mutation/IO to a framework or external service. This is what haskell does, but you see this is just shifting the problem to somewhere else. Someone somewhere still had to deal with the issue of mutation. Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.

Segregation of mutation/IO into a framework is a good thing. It makes it so that the problem can be solved one time, rather then a problem solved many times. However the main point of my post is to say that "math" or "algebra" is not a one size fits all solution. You cannot model everything this way, moving the problem into a framework does not make the problem disappear. Someone still had to use imperative primitives to deal with the issue. Think about the complexity of a SQL database.

[phizy]

You said FP "breaks down" when handling mutability, and you attributed that to some vague sense in which "mathematics" is the cause of it.

I have no bias for FP. I just don't understand what you're getting at.

>the purity of haskell does not remove the necessity of mutating data in that database.

That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.

>Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.

Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.

Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.