Quoth Chris Smith
The answer is that side effects has become something of a figure of speech, and now has a specialized meaning in programming languages.
When we're talking about different uses of the word "function" in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values.
I'm surprised by the use of "function" as a unit. I would have expected "expression" or something, but maybe that isn't semantically interesting as long as one can't exist independent of the other.
... But C extends the definition of a function to include additional effects, like making "Hello world" appear on a nearby computer screen. Because those effects are "aside from" the taking of arguments and returning of values that functions exist to do, they are "side effects"... even though in the specific case of printf, the effect is the main goal and everyone ignores the return value, still for functions in general, any effects outside of producing a resulting value from its arguments are "side effects".
If that's so, it's unfortunate. It would have been more profitable to confine the application of this term (side effect) to the context of the program, where it 1) makes sense in English, and 2) applies to a programming device that has always been of some interest. I have a little trouble defending this point of view because there's some overlap, inasmuch as the program may also retrieve values via external I/O. And Haskell provides writeIORef/readIORef as a convenient way to demonstrate that as a technical side effect without resorting to actual I/O. Still, the use of I/O and similar techniques to create a side effect are interesting as such, and my point is that if we call every I/O a side effect, the term loses its value as a way to describe this programming feature. Donn