4 ms·

No, he’s saying that it is a language closer on the spectrum to useless than useful- and that is because side effects are an afterthought/discouraged rather tha

No, he’s saying that it is a language closer on the spectrum to useless than useful- and that is because side effects are an afterthought/discouraged rather than a first class citizen. The only potential for misunderstanding the headline is if you fail to see that it’s hyperbole. Otherwise I don’t see how it’s being taken “out of context”.

chris_wot 3y ago
No, that's not what he's saying. The original post you are responding to is correct - he produces a quadrant that maps "usefulness" to "safety". Safety was dealt with by removing side effects. Nowhere does he state that side effects are an afterthought or discouraged, what he says is that they need to work out how to seperate code that produces side effects from code that has no side effects.
- ShamelessC 3y ago
  What you just said seems to be in agreement with what I said.
  - chris_wot 3y ago
    You stated that "side effects are an afterthought/discouraged" and I stated that "nowhere does he state that side effects are an afterthought or discouraged".
    - 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 ago
        It 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.

chris_wot 3y ago

No, that's not what he's saying. The original post you are responding to is correct - he produces a quadrant that maps "usefulness" to "safety". Safety was dealt with by removing side effects. Nowhere does he state that side effects are an afterthought or discouraged, what he says is that they need to work out how to seperate code that produces side effects from code that has no side effects.

ShamelessC 3y ago
What you just said seems to be in agreement with what I said.
- chris_wot 3y ago
  You stated that "side effects are an afterthought/discouraged" and I stated that "nowhere does he state that side effects are an afterthought or discouraged".
  - 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 ago
      It 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.