Language matters. I don’t know about you, but I think the words used when speaking about functional programming (FP) have an elitist tinge to them. With FP, we are encouraged to use “pure” functions, which, of course, implies that we have been doing impure things all this time. I’m not a psychologist, but I bet this kind of talk can stimulate the subconscious into engaging in a bit of self-loathing for our impure transgressions.

And what about these “side effects” that we routinely traffic in? We know what the term “side effects” usually means: medicines are used for their beneficial intended effects, but we are warned against their many possibly pernicious “side effects.” But front end web developers write code that intentionally interacts with users and the real world, right? Because these interactions are intentional, they certainly are not “side effects” in the customary sense of the term. But in the language of FP, these are called “side effects,” which implies harmfulness. It seems like another attack at the very heart of what we do. Coders who are introduced to FP for the first time are hit with an immediate one-two punch!

Okay, I know there are very good reasons to shift our coding practices to functional techniques. Maybe to aid in the transition, we can playfully invent new, non-judgmental terminology for the uninitiated (any suggestions?), or even drop some of the more specialized FP terms. I think Evan Czaplicki, the developer of the Elm language, has made good progress in bridging the gap between mainstream front end programming and the more rarefied world of FP (like thinking of monads as callbacks). Also, the latest version of JavaScript incorporates more additions to the language that help ease the transition.

With regard to variables, they are called variables because we expect them to vary, right? Now, what’s all this I hear about the harmfulness of “mutating” state variables? Here we go again…