5 ms·

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I tak

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I take your point that a lot of imperative programming is done in Haskell (e.g. State monads). However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

Geminidog 6y ago
>You seem to be lumping all side-effects together as equally bad? Never implied anything was bad or good. Just saying that Haskell style programming does not push side effects to the edge. >I don't think you can expect to push everything out to the edges, for example partiality. Of course you can't push everything to the edge, but haskell style programming doesn't attempt to do this. It embraces the side effects and no one actually pushes anything to the edge. Partiality was just an example, the point is the bind operator will have a side effect on b so you can no longer treat the output of b as a pure black box. People who use haskell use the bind operator all the time indicating that their code is littered with side effects. Which again isn't necessarily bad, it just is what it is. >However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects. But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation. Again if you avoid using monads as much as possible in haskell you are pushing side effects to the edge. If you don't do this, which is basically what most haskell programmers end up doing, then you are not pushing side effects to the edge.
- tome 6y ago
  > But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation. Yeah, "functional core/imperative shell" or "pushing IO to the edges" is a weird myth. Really the strength of Haskell is "functional core/IO code carefully threaded through functional core". What's a good descriptive slogan for that? "Functional pipework/imperative reactants", invoking chemical engineering? To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell.
  - Geminidog 6y ago
    >To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell. Yeah agreed, it's just a style of programming within the functional paradigm. Not necessarily bad or good.

Geminidog 6y ago

>You seem to be lumping all side-effects together as equally bad? Never implied anything was bad or good. Just saying that Haskell style programming does not push side effects to the edge. >I don't think you can expect to push everything out to the edges, for example partiality. Of course you can't push everything to the edge, but haskell style programming doesn't attempt to do this. It embraces the side effects and no one actually pushes anything to the edge. Partiality was just an example, the point is the bind operator will have a side effect on b so you can no longer treat the output of b as a pure black box. People who use haskell use the bind operator all the time indicating that their code is littered with side effects. Which again isn't necessarily bad, it just is what it is. >However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects. But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation. Again if you avoid using monads as much as possible in haskell you are pushing side effects to the edge. If you don't do this, which is basically what most haskell programmers end up doing, then you are not pushing side effects to the edge.

tome 6y ago
> But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation. Yeah, "functional core/imperative shell" or "pushing IO to the edges" is a weird myth. Really the strength of Haskell is "functional core/IO code carefully threaded through functional core". What's a good descriptive slogan for that? "Functional pipework/imperative reactants", invoking chemical engineering? To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell.
- Geminidog 6y ago
  >To cycle back to your point, I don't think the failure of this slogan actually points to any weakness in Haskell. Yeah agreed, it's just a style of programming within the functional paradigm. Not necessarily bad or good.