
On 31/08/2015, at 2:47 pm, William Yager
On Sun, Aug 30, 2015 at 8:20 PM, Richard A. O'Keefe
wrote: 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.
Wrong definition, my friend.
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
Sorry, cliekd the wrong button. If you had troubled to read the Wikipedia article with care, you'd have seen this right at the beginning: In computer science, a function or expression is VVVVVVVVVVVVVVVVVVVVVVVV said to have a side effect if, in addition to returning ^^^^^^^^^^^^^^^^^^^^^^^^ a value, it also modifies some state or has an observable interaction with calling functions or the outside world. You have a function, whose purported effect is to return a value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE", "A SECONDARY RESULT". The Wikipedia definition is slightly wonky in that if you take it literally, a Fortran subroutine = Pascal or Ada procedure = C 'void function' can't have a side effect, which is obviously wrong. A subprogram that does not return a value *CAN* have a second result other than the one it is declared to have, and the need to consider history in reasoning about resultless procedures is none the less because of this glitch in the Wikipedia's definition.