Commonly used terms get abbreviated. Thus functional programmers often say “effect” instead of “side effect”. I approve of this usage – not only because it's shorter, but because it frees up “side effect” for another concept. This is something assembly language programmers know, and have known for decades, that other programmers seldom speak of.
Most machines have no notion of a return value; the only way for parts of a program to communicate is by mutating registers. So assembly language programs must do all their communication by effect. This means they distinguish between different kinds of effect. In particular, they distinguish effects that are part of a routine's contract from those that, however consistent, are not intentional: side effects.
Consider this implementation of factorial on a typical register machine:
;The factorial function, iteratively
;args: r1 = n
;results: r2 = n!
;All other registers are preserved.
factorial:
li r2, 1
loop:
cmpi r1, 1
ble done
mul r2, r2, r1
sub r1, r1, 1
b loop
done:
retThis function leaves its result in r2, but also happens to set r1 to 1. This is a side effect: an effect not in the routine's contract. It is, of course, a bad idea to rely on these, but by accident or desperation, assembly programmers occasionally do, which is why they have a name for them.
(Recursive factorial is more complex than iterative on most machines – often absurdly so, if you strictly follow an ABI that wants you to save registers and construct stack frames. This is one of the reasons programmers accustomed to low-level languages don't take readily to recursion. To them, it looks unnecessarily complex, because it is complex in implementation. High-level languages hide this complexity, but low-level programmers know it's still there.)
It's not normal for programs in higher-level languages to have side effects in this sense, because they have fewer ways to accidentally have effects. Supposedly unobservable effects like preloading caches are common (and are occasionally relied on), but typically any observable effect that isn't part of the interface is a bug. So this concept is less useful in higher-level languages. The more general concept of relying on unspecified behaviour remains useful, though, and it's quite familiar from discussions of language specs.
Functional programming advocacy suffers from a focus on purity, where state is considered a sin to be avoided absolutely. One way the movement might make progress is to distinguish between different kinds of effects, so they could say which ones are deadly and which are venial, rather than treating all effects as indistinguishable evil. Vocabulary analogous to the assembly language programmers' “side effect” might help with this.
Pure FP advocates often do believe that observable effects outside of returning a value are an 'indistinguishable evil'. I'm certainly of this opinion. We're not against effects. But we'll model effects, including state updates, via the return value. E.g. a simple purely functional model suitable for actors/machines is: (InMessage, State) → (List of OutMessage, State). Usefully, it is possible to model entire networks of these machines in a purely functional manner. We could capture this behavior via writer-state monad, but an explicit function might be easier for newcomers to grok.
ReplyDeleteThe main difficulty with FP advocacy, as I understand it, is that imperative programmers simply aren't prepared to grok a pure approach to modeling effects. They're too used to `public static void main()` as the signature for an application, which certainly admits no effects via the return value.