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

[nerdtime]

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

Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program modelling mutation if the program can't actually do mutation or IO.

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

Location meaning outside of haskell. Like your database. I'm saying within haskell you have a variable.

  x = 3

You can never mutate that variable in haskell. However you can mutate the state of the console without ever mutating any state within haskell.

    print "hello"

The above triggers no mutation in haskell. A runtime outside of the haskell universe analyzes the IO instructions and mutates the console. What I am saying is that the thing that mutates the console has to do mutation. Whoever wrote that thing HAS to write imperative primitives. They are moving the imperative nature of programming INTO a framework. They are not eliminating the problem.

This is the same thing as a database string. UPDATE. You are moving all the imperative errors that have to deal with threading and mutations to the database. But your haskell sql string is still pure.

Again my argument is just saying that this thing that is doing the UPDATE or mutating the console cannot be built using haskell style code or immutable algebraic concepts. Imperative primitives need to exist and someone needs to use those primitives to do the actual mutations.

The OP is basically saying algebra is the future and it can replace everything. I'm saying it CAN'T.

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

And honestly you sound like the guy standing on the iron boat. The person I'm shouting at is you, but you're just dismissing me.