On 29/08/2015, at 8:41 pm, Alexey Muranov
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?