Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.
To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell.
>The presence of monads does not necessarily mean side effects
The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own.
For example let's say I have a maybe monad that will never produce "Nothing."
b :: int -> Maybe Int
b x = Just x
Nothing >>= b
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.
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.
Yeah agreed, it's just a style of programming within the functional paradigm. Not necessarily bad or good.