Re: [Haskell-cafe] side effects (Why Haskell is beautiful to thenovice)

On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:

quoth ...

...

I see someone has changed it back to the old muddled wreck, sigh.

I sympathize with what I understand to be the point, that it's silly to call an effect that's clearly central to a computation a "side effect."

That said, it sure is widely used that way, and an attempt to correct this is not only swimming upstream, it also encounters ambiguities that the common definition avoids.

"Eat feces; billions of flies can't be wrong!" Seriously though, the distinction between an *effect* and a *side effect* is important, and using the term "side effect" to indicate either is just as ambiguous.

I think the FP paragraph on this page could be much better - "The functional language Haskell expresses side effects such as I/O and other stateful computations using monadic actions." That's it? Can this be written so it would address what Haskell brings to the problem, in a way that would make sense to a Java programmer?

It could certainly be better; it's not only vague, but also misleading, further fueling the Monad Confusion. Haskell expresses effects by making them first-class, i.e., introducing values that represent the effects, functions to combine and manipulate them in a pure fashion, and the convention that the value bound to Main.main represents the computation we want the runtime to execute. IO also happens to be a valid Monad instance, but that's more a convenience thing, it's not essential to encoding effects at all - one could easily implement an IO minilanguage that doesn't implement Monad; it would end up taking a Monad shape at some point though, so it makes sense to make it official by having it implement the Monad typeclass. But that's not essential for the mechanism at play here - it just so happens that effectful computations usually end up forming monads.