4 ms·

while I agree with your overall argument, i think this is wrong: > And pure functions are probably best tagged with an asterisk because most of the time you ha

while I agree with your overall argument, i think this is wrong: > And pure functions are probably best tagged with an asterisk because most of the time you have state to manage somewhere purity does not mean there is no state! This is exactly what the monad (and similiar structures) in haskell is for, which you correctly mentioned. But they don't violeate the purity.

foolfoolz 8y ago
i think it devolves into semantics at that point. when each line is doing some DB query or remote HTTP call it rarely matters if it's in a monad or not
- LeanderK 8y ago
  well, i think it does matter! Especially if you're pure (or try to be) it really matters, because you need constructs like monads to remain pure.
- yogthos 8y ago
  Exactly, whether you use a monad or not is an implementation detail. The high level idea is that you decouple the code that does IO from the code that's responsible for the business logic.
gh02t 8y ago
This is kinda debatable. There is still state in Haskell, regardless of how it's compartmentalized. The implementation of the IO monad for example must rely on state to function, because IO is inherently stateful. You may not have to deal with it as much, but under the hood there is still state. And this matters in practice, because sometimes the desired effects of your program are inherently stateful. For example, if you want to have lines of text output to the terminal in a certain order, you have to at least think about state at some level. If Haskell was truly free of any state, this would be impossible to guarantee. What I will agree with though is that it's mostly possible to ignore state in Haskell, and that individual pure functions are truly pure. My point is that those pure functions can't do anything without invoking state at some point.
- LeanderK 8y ago
  but I don't see how you are debating me! I mostly agree, but that's my argument :) > If Haskell was truly free of any state, this would be impossible to guarantee. I was never claming that haskell was free of state, i was claiming the opposite! That state and purity are not mutually exclusive, they just result in constructions like monad.

foolfoolz 8y ago

i think it devolves into semantics at that point. when each line is doing some DB query or remote HTTP call it rarely matters if it's in a monad or not

LeanderK 8y ago
well, i think it does matter! Especially if you're pure (or try to be) it really matters, because you need constructs like monads to remain pure.
yogthos 8y ago
Exactly, whether you use a monad or not is an implementation detail. The high level idea is that you decouple the code that does IO from the code that's responsible for the business logic.

gh02t 8y ago

This is kinda debatable. There is still state in Haskell, regardless of how it's compartmentalized. The implementation of the IO monad for example must rely on state to function, because IO is inherently stateful. You may not have to deal with it as much, but under the hood there is still state. And this matters in practice, because sometimes the desired effects of your program are inherently stateful. For example, if you want to have lines of text output to the terminal in a certain order, you have to at least think about state at some level. If Haskell was truly free of any state, this would be impossible to guarantee. What I will agree with though is that it's mostly possible to ignore state in Haskell, and that individual pure functions are truly pure. My point is that those pure functions can't do anything without invoking state at some point.

LeanderK 8y ago
but I don't see how you are debating me! I mostly agree, but that's my argument :) > If Haskell was truly free of any state, this would be impossible to guarantee. I was never claming that haskell was free of state, i was claiming the opposite! That state and purity are not mutually exclusive, they just result in constructions like monad.