[Haskell-cafe] Why Haskell is beautiful to the novice

[Richard A. O'Keefe]

On 29/08/2015, at 8:41 pm, Alexey Muranov <alexey.muranov at gmail.com> wrote:

> IMO, what attracts a big part of kids to programming is the possibility to program side effects.

Language changes.  Sometimes it changes in obfuscatory ways.

Take this example:

    PRINT *, 'HELLO WORLD!'
    END

That's a complete Fortran (77, 90, 95, '04, '08) program.
The print statement has an EFFECT.  That effect is not a
*SIDE* effect.  Here's the definition of "side effect":

1. A subsidiary consequence of an action, occurrence,
   or state of affairs; an unintended secondary result.
2. An effect (usually for the worse) of a drug or other
   chemical other than that for which it is administered

In the case of the little program above, the fact that
output is sent to a destination is neither subsidiary,
nor unintended, nor secondary, nor other than that for
which the program was constructed.

I flatly deny that "UNINTENDED ... results" are what
attracts ANYONE to programming.  Effects, *YES*;
*side* effects, NO.

As a young programmer, decades ago, I learned to be
perfectly happy with *effects* but wary of *side effects*.
(By getting it wrong of course, how else?)
Confusion of *words* leads to confusion of *thought*:
I didn't want anyone taking my READ and PRINT statements
away but I *loved* the idea of languages where you told
the compiler "this procedure can read these variables and
write those variables", as in SPLint for C.

To call the main, principal, intended consequences of a
program element, the entire reason for its existence in
the program, to call *that* a "side effect" is just to
blue a vital distinction.

You see, when people in the programming world got worried
about side effects, they were not in the least worried about
known, intended effects.  They were worried about "functions"
that printed output, "functions" that changed hidden variables.
Nobody minded things like

    CALL RANDOM_NUMBER(HARVEST = X)

or even

    U = NRAND(SEED)   ! update SEED

They were worried about things like

    lu = random();

which *purports* to be a function call, and is called in
order to obtain a value, but *also* has a "subsidiary
consequence" which is hidden from the programmer, the
compiler, or both.

Now what Haskell does is to banish side effects completely.
You can have all the effects you want, but *something*
about the scope of the effects must be visible in the type,
and effectful operations have to be explicitly chained in
a way that "pure" operations do not.

If we screw up our language by calling all effects "side
effects", we can't even *think* "Haskell makes effects easy
but side effects hard".

To anyone who wants to defend the abuse of "side effect",
what do you think is the point of the word "side" in that
phrase if not to distinguish side effects from some other
kind of effects?