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

[Donn Cave]

Quoth Tobias Dammers <tdammers at gmail.com>,
> On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:

> 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.

It isn't, because they avoid the matter of intent.  If you call
every change to state context a side effect, then you're down
to fine points about state, context, etc.

Anyone can see the importance of a distinction between effect
and side effect, but that doesn't make it easy to draw up a
definition that could easily be applied to any expression to
tell us whether the effect is a side effect or not.

Rather what I'm saying is, let the billions of flies have it
their way, but use the FP paragraph to illustrate more appealing
culinary techniques for clean and wholesome dining.  Functional
languages are by nature less dependent on side effects, with
features like single assignment, efficent recursion, am I right?

I agree with your thought to deemphasize the monad part of the
Haskell explanation.  It might be a mistake to try to really
explain how Haskell does it, maybe better to just say that
Haskell rigorously distinguishes expressions that have external
side effects and provides a mechanism for their ordered execution.
If you get too deep into it, you have to explain that, well, IO
isn't just for side effects but accounts for any external state
dependency, etc. - and all in terms that will easily be understood
by an average Java programmer.  (That's why I'm pursuing this,
in my position as surely the least erudite member of this
mailing list, I hope to be able to recognize a suitably simple
minded explanation when I see one.)

	DOnn