4 ms·
I was paraphrasing, inferring. I didn't mean to make a strong claim about Haskell specifically, but about how side effects correlate with software being useful
by ShamelessC 3y ago
I was paraphrasing, inferring. I didn't mean to make a strong claim about Haskell specifically, but about how side effects correlate with software being useful - a point that I think Simon would agree with.
I still think you and I are in agreement? And indeed, Haskell is closer to being a language that discourages/protects against side effects than one that allows them without regard for the complexity they introduce.
- chris_wot 3y agoIt does look we have been talking cross purposes :-)
- louthy 3y ago> Haskell is closer to being a language that discourages/protects against side effects than one that allows them without regard for the complexity they introduce. Haskell doesn't discourage side effects at all, it simply makes them declarative in the form of monads. All monads, whether they're the IO monad or not, are about handling side-effects and then being explicit about it wherever they're used. So, if you use an IO monad in the middle of your pure function then that function becomes an IO function and it spreads out from there (like async/await in other languages). This encourages you to partition your effectful and non-effectful (pure) code. It doesn’t discourage effectful code. When he talks - about having more control/safety - this is how Haskell deals with it: by being declarative, not by discouraging or shying away from side-effects. This whole thread gives the impression that Haskell doesn't want to have any impact on the world around it, which just isn't the case. The fact the `main` function is an IO operation kinda proves that. SPJs comments are clearly tongue in cheek and self-deprecating in the extreme.