Quoth Tobias Dammers
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