I like the diagram, it looks useful. I might call it something like “calling pure functions versus calling side-effecting functions”
Whether it’s well-known depends on the audience—it’s certainly “new” in some sense to people used to imperative side-effect-driven development, and it’s certainly new to 100% beginners just getting into programming.
When I teach this concept I use “somewhere else” to highlight the contrast between side effects and return values. Usually I do this with two or three examples:
- I call the fn with value x (or values x, y…), it gives me value y based on x, nothing else happens anywhere in the universe, everyone is happy
- I call the fn with value x, it gives me value y based on x, but it also changes something somewhere else (without telling me and which I have to “just know” about); sometimes this is necessary but take care with it
- I call the fn with value x, it gives me y based on x and some other stuff from somewhere else (which I have to “just know” about); sometimes this is necessary but take care with it
Of course there’s a fourth situation combining 2 and 3 which may or may not be useful or necessary to explicitly delineate. Since the diagram includes it, I would tend towards being explicit. That also means I would recommend naming that second dimension in the title of the section and diagram title: “pure fns, side effects, and external factors” (or “state”).
I find it useful to state the pure fn approach as “the way”. I then reiterate “sometimes side effects are necessary” from multiple angles, which (somewhat contrarily) helps reinforce the pure-fn approach as the approach to strive for. I emphasize in turn how side effects are usually not necessary, how avoiding these other inputs & outputs makes the fn and system simpler to reason about and prevents surprises, and I point out some specific examples of when it is necessary, as well as how to contain/minimize/mitigate the problems of side-effecty programming.