The phrase “euphemism treadmill” refers to the process by which ordinary words referring to uncomfortable topics end up becoming “loaded,” branded as uncouth words per se, and thus discarded in favor of new words which haven’t yet had the chance to become loaded — which, a few years or decades later, are discarded in turn. To take the most obvious example, the Online Etymology Dictionary claims that lavatory is attested from 1864; toilet from 1895; bathroom from the 1920s; restroom by the 1930s. Of course all these words pre-existed; but they took turns being the mainstream American euphemism for “that room with the toilet in it.” See Angela Tung’s “A Brief History of Lavatory Language” (September 2015).
I’ve occasionally observed a superficially similar phenomenon that happens in technical fields: an ordinary English word will be adopted as technical jargon with a specific technical denotation, which confounds any attempt to use that word (in technical writing) with its ordinary colloquial meaning. The freshest example is the word “concept.” I’d been used to saying and writing things like
In C++, initialization and assignment are two completely different concepts
but these days that phrasing seems likely to lead to confusion on the part of some readers — “Wait, those are concepts?
What’s the definition of assignment look like as a concept?” So since 2017-ish I’ve made a conscious effort
to switch to unloaded words like “notion” or “idea.” For example,
in “P0732R0 and trivially comparable” (2018-03-19)
I talked about “C++’s notion of trivially destructible.” C++20 does, literally, have
the concept of
trivial destructibility has been downgraded in my book to a mere notion.
A much older example — so old that you and I probably didn’t live through when it happened — was the loading of the word “type.” I would certainly avoid saying something like
This routine handles input of two different types…
unless I was talking literally about two different types. Otherwise I’d try
to say something like “input of two different kinds.” But then yesterday in the context of Mateusz Pusz’s
units library I wanted to write something like this:
We have data types such as
area, which represent sort of abstract quantities in our system, and then we have other identifiers such as
surface_area, which represent domain-specific strong types that we really don’t want to mix up. The current naming scheme fails to make it sufficiently clear that
width) are completely different kinds of types…
Well, it turns out that ISO/IEC 80000, the technical standard in this particular domain, gives a specific technical meaning to the word “kind”!
kind of quantity
aspect common to mutually comparable quantities
Unfortunately, in ISO’s terminology,
width are two different quantities of exactly the same kind.
So, at least in this particular domain, I must find a new English word that means “type” — er, “kind.”
For now I’ve settled on “sort”:
cross_sectionare completely different sorts of types…
Are the jargon-inventors going to come next for “notion” and/or “sort”, forcing another step on the jargon treadmill? In practice I wouldn’t bet on it — but it does keep me up at night.
I suspect that the same phenomenon exists (and even more strongly, that it existed) in mathematics, which in the 18th and 19th centuries consumed English words like “set,” “group,” and “category” at a rapid clip: you might struggle to find an unloaded word if you were just trying to talk about an, um, collection of interesting mathematical objects.
I also suspect that the phenomenon exists to some extent in criminal law. Rather than referring to someone’s behavior being a nuisance (which in most jurisdictions has a specific jargon meaning and thus might in some contexts be plausibly mistaken for an attempt to allege or imply a crime had been committed), a lawyer might use a less loaded word like annoyance (which I think hasn’t been co-opted as jargon… yet).
Have you experienced this phenomenon in your technical field? I’ll add examples here if I hear of any.
- “WG21: Avoid creating ADL situations on functions with semi-common names” (2018-11-04)
describes the source-code version of this notion, in which “nice” names for free functions (like
hash_value) must be replaced with progressively uglier names.