>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.
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.
>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.
>You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.
Why the heck would I run such a long expose and troll you and be mistaken at the same time.
>How does this Haskell program write to stdout if it doesn't mutate memory?
Let's not be stupid here. Every program on the face of the earth must mutate memory because that's how computers work. Assembly instructions mutate things. We're not even talking about that. We're talking about application level programming where we only deal with primitives that the application programmer is aware about. I am saying that at the application level within the category of Hask nothing is mutated.
In your example tell me what haskell primitive.... What variable or data was mutated within haskell? That is what I'm referring to.
Try to implement IO or ST in another lang using only purely functional primitives. Use your algebra to make it work. You'll find it's impossible. What this means is that imperative primitives must exist for any programming to work.
>Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur.
Obviously I'm operating on a certain layer of abstraction here. In X = 6, X is obviously immutable in haskell. A runtime is obviously executing your haskell program and mutating the console but your haskell code itself is pure. But you know this. It's quite obvious you're the one that's trolling.
>What variable or data was mutated within haskell?
The stdout buffer.
Just because mutation isn't explicit doesn't mean it isn't there. Programming languages are not syntax devoid of meaning: they have semantics. What happens at runtime is part of what a programming language does. (Arguably, that is the most important part of what they do.)
>What this means is that imperative primitives must exist for any programming to work.
That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa. Again, they're just different models. No language can do anything if it isn't implemented in a machine. A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction. You absolutely could implement a pure functional assembly language. The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].
Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.
> Use your algebra to make it work. You'll find it's impossible.
Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.
The stdout buffer is not part of the haskell language, it is part of the OS. The haskell runtime reads the haskell language and accesses the buffer. Neither the runtime or the buffer is part of the haskell language, get it? That's why haskell is called "pure" Category Hask: https://wiki.haskell.org/Hask#:~:text=Hask%20is%20the%20cate....
>Just because mutation isn't explicit doesn't mean it isn't there.
So? I never said it wasn't there. I'm basically saying as far as the programmer is concerned when operating within the haskell language no haskell language primitive is mutating. stdout buffer is not a haskell primitive... it is an OS primitive.
>That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa.
This is true theoretically, but physically but you can't actually build a functional machine. Lisp isn't actually a functional language and you'll see from the instruction primitives that the lisp machine is more or less a turing machine that mutates memory.
>No language can do anything if it isn't implemented in a machine.
So? Never said this wasn't true.
>A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction.
The machine you build is limited by what you build it with. You have a limited set of atoms. Therefore you can only build a machine with limited amount of state. In order to use the state efficiently the state must be mutable. Mutable state means imperative instructions. You can imitate functional programming with such a machine and you can sort of solve the memory problem with garbage collection. But with what paradigm do you implement the garbage collector? Imperative primitives.
> The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].
No the real reason is also because it's physically impossible. A physical translation of a actual lambda machine cannot be realized. What they can make is register based machine that are more efficient at compiling certain functional languages that's it. All machines we build have some sort of state that changes.
>Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.
Sure I can prove what I said. But you're changing the problem from IO and ST to a computable function which I assume is algebraic. So of course all of algebra can be used to create all algebraic functions. I'll just prove what I said rather than what you changed it to.
Assuming mutation is an axiomatic operation that cannot be built from immutable operations, you will see that no mutation operation exists in algebra indicating that mutation cannot ever exist in any theorem of algebra:
You will see that no algebraic operation involving mutation exists in the above document.
>Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.
No but I can implement volatile with imperative primitives from other languages. All I am saying is you cannot implement ST and IO with functional primitives.
Personal attacks are against site rules on HN. You are clearly across the line here. Moderators ban people for repeated violations, so if you want to continue here, you should stop posting abuse.
You can do better, then. Read nendroids latest reply to me, and help them understand that it's the "use of statements" that makes a language imperative, not the "modification of state."
I won't be responding, and they seem to think they're quite the expert in this sort of thing.
"In computer science, imperative programming is a programming paradigm that uses statements that change a program's state."
The above quote is ripped straight out of wikipedia's definition of imperative programming showing that what I said wasn't a misunderstanding but an official definition.
The definition of imperative programming must include mutation otherwise it's isomorphic to functional programming. Because functional programming is simply statements without mutation.
Case in point, This guy turned what was just fact checking into something personal. See, it's not about being civil. That's just the way people like to think they are. The reality is most people can't accept being wrong and they can't accept opinions they disagree with and the irony is everyone believes they're above this base behavior.
"In computer science, imperative programming is a programming paradigm that uses statements that change a program's state."
You will see from the quotation above. The very act of changing state is an imperative style by definition. The purpose of mutable state is for it to change. So mutable state = imperative instructions.
>You don't have to listen to me, but you should seek out a second opinion from a competent person who can get through to you.
I'll throw that advice back at you. But you don't need to find that person. I'm right here in front of you telling you how it is.
>Everything I said in my last post is basic, well-understood computing knowledge. If you want me to disagree with it, you need to find yourself a competent computer scientist to aid you in framing your ideas in a way that is comprehensible with respect to the subject matter.
Yeah but you didn't account for the practical parts of computing. The theoretical parts often deal with machines that can't be realized in reality. It's pretty much common sense. How do you represent a function call without mutable state? How can you have a machine do an algebraic operation without mutable state? The very act of holding that information in state requires a state change meaning to even load a lambda machine with a program requires an imperative instruction.
We're also in a corner of computer science that isn't formally well defined. A language can be formally defined as pure but there's no formal theory for systems design and how the system overall influences the content of a pure SQL string in Haskell.
I define a haskell sql string to have syntactically correct SQL. The external requirements of my database are forcing me to define a string this way, is that a side effect? There's no formal rules in literature so it's just raw talking points... you won't be able to find an official source stating who's right or who's wrong.
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.