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

[Tobias Dammers]

On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:
> quoth <ok at cs.otago.ac.nz>
> ...
> > 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.