The Relativity of Naming
Before the pandemic hit, there was a loosely organized weekly lunch among the local developer group – typically meeting somewhere downtown and organized on the group’s Slack, which of course ceased along with the beginning of the COVID quarantine era. About a year into that, a subset of that group (including myself) started meeting for lunch on the patio of a pizza place within a mile of where we all lived; others who lived elsewhere in town were invited, and it was a nice way to commiserate and break the tedium of that era. The developer group Slack atrophied during this time and we’ve kept up the weekly pizza lunches to this day.
Then one of the original group who lived near me moved across town. I live in one of those cities bisected by a significant enough body of water to impact addressing and naming of areas – in our case, “west” and “east” sides – and this shifted the balance of regular attendees enough that we started alternating between meeting on the west and east sides of town. The pizza place’s location where we’ve usually met on the west side is called the Westside location, but the one on the east side is named after the neighborhood it’s in (presumably because this is in an outskirt corner of the city limits) and we sometimes met at this east side location, coordinated on group chat. Everyone referred to the location on the east side as the Eastside location, and everyone knew what was meant because there was only one location of this pizza business on the east side of the water bisecting the city.
And then about two years ago the pizza business opened a third location, also on the east side of town, and named it the Eastside location — presumably unaware of the colloquial naming in our group chat. The original location on the east side of town (the one named after the neighborhood) is more convenient for most of the people who live on the east side of town, but since it’s difficult for those on the west side of town to get to – there are no direct bus lines, and lunchtime parking is highly contentious – we typically meet somewhere downtown instead. But occasionally, due to people being out of town, weather, or some other circumstance, there’s an opportunity to meet at the original location on the east side (the one named after the neighborhood) and some people in the chat still refer to it as the Eastside location, while others interpret that to mean the location officially named Eastside.
Those of us who’ve been in the chat for a while can typically gloss over this because of collective context, but because of the type of work that I do, the imprecision and opportunity for confusion bothers me: Someone new to the chat and aware of all three pizza business locations could accidentally go to the location properly named Eastside and then wonder why no one else showed up. This hasn’t happened yet, but it could and that kind of preventable confusion is something I care about.
This sort of colloquial papering-over of naming happens all the time and for the most part it doesn’t cause much confusion, largely because people tend to be aware of the idea that a name can mean multiple things, and one can generally pick up on contextual cues that perhaps someone understands a name to refer to something other than what one is intending it for. Computers are not good at contextual clues – they do what we tell them to, and exactly what we tell them to; because it’s hard to be perfectly precise in natural languages, we don’t use those to program computers, we use “code” instead.
There’s a joke in programming circles: there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors, which is often used as a dig at the horrible mistake♦︎ of zero-based numbering, but there is truth in the idea that both cache invalidation and naming things are indeed hard problems. One of my favorite books about programming (for any language, really), Elements of Clojure by Zach Tellman, devotes one of its four chapters to the fine art of naming.
I don’t want to postulate here about what makes for a good or bad name; rather, I want to point out the tenuous network of associations that allow a name to be good or bad to begin with, and how fragile those can be. Names are hard because a good name requires both context and an adequate amount of pith – defined by my dictionary as the essence of something and a forceful and concise expression. Words like “essence” and “forceful” speak to the idea that good names often rely heavily on the larger context in which they’re used; sometimes a greater context takes precedence, but more often a local and specific one takes precedence instead.
Navigating these contexts can be tricky and for smaller contexts; names are often more in the realm of either culture (this codebase uses the internal codename comrade to refer to individual login accounts in an attempt at solidarity, one of the project’s values) or lore (this codebase refers to individual login accounts under a group account as peon instead of user because the original engineering hire thought it was funny), and neither of these things tend to be documented well, if at all; they’re the sorts of things you learn as you go, and therefore somewhat fragile.
Changes in the greater context can ripple into changes in the smaller one, like in my story about pizza lunches, or for example the artist names of music acts such as the experimental electronic artist Twerk or the progressive post-metal group ISIS, a name also used – and changed – in the animated series Archer, but changes in the larger context are often driven by some other smaller context becoming important enough to gain attention outside of it. Names become good or bad based on their associations and invocations, and those associations can – and do – change. What is a good name for something now could become a bad name in the future.
Naming is a part of language, and languages as spoken are organic, not controlled; when the context around a name changes enough to warrant finding a new name because it has become bad, how does that happen? Presumably with Archer, someone with enough authority dictated that a change should occur, and change followed (I don’t actually know this, I’m merely guessing). Sometimes it takes enough people caring about something to to make enough noise about a problem so that a billion dollar company changes a default name. Sometimes it takes one person noticing a problem and caring enough that they attempt to herd cats; and maybe that means caring enough to point out something that should be obvious, even if no one else thinks so.
♦︎ On Counting vs Measuring ↩
This idea really deserves its own essay, but here’s the short of it:
Measurements of things are typically continuous values using some sort of unit and can include zero in some way; as with temperature, where the as-I’m-writing-this temperature outside is 46 degrees Fahrenheit or 7.8 degrees Celsius; two scales whose units measure the same thing in different amounts and with differing reference points. We measure age in years, and typically round that; we refer to a newborn as “two weeks old” because they have completed zero years, and – despite our entire vocabulary around it, time is a continuous value: epoch time isn’t counting seconds since January 1, 1970; it’s measuring the time elapsed in seconds since then.
Counting of discrete items typically starts at one. You can have “zero pigs” just as I have “zero yachts” or “zero spacecraft”, but when you do have some pigs you start counting them with the number one. That the first item in an array is indexed at zero is a billion-dollar mistake on par with null references. It would be possible, I suppose, for me to have 1/1000 of a spacecraft just as I technically have one-half of a car or house (my spouse having the other half), but the number of spaceships involved is still one and my ownership of it would be merely fractional; I could just as well have 1/1000 ownership of 1000 individual spacecraft, but that doesn’t mean I own one complete spacecraft by myself. The car or house or spacecraft is a discrete thing – in a manner similar to the joke about the average person having 2.3 children.
I have a rule of thumb for distinguishing which act a number represents: if you cut a thing in half or quarter or whatever, does that change what it is? You can cut an hour in half it’s still an amount of time, just as you can cut a stick of butter in half and it’s still butter. If you cut a car in half it’s no longer a car; perhaps it’s a bunch of scrap, perhaps it’s a museum exhibit, but a car it is no longer.
All of this said, changing the conventions of programming environments such that the first item in an array use an index of 1 would be an effort on par with eliminating timezones, as I have become convinced by my efforts of going back and forth between Lua (which does the right thing by custom starts indexing arrays at 1, though really any value will work) and other languages which do the conventional thing of starting array indexes at zero.
Further Reading
What’s in a name?
A very good piece from Jane Street about how naming is a process of symbol creation, and how manipulating those symbols in computer code is in-turn influenced by the choice of names for those symbols.
Name choices inflict specific thought processes on people who use them; bad name choices inflict perverse or misleading thought processes, and make it hard to understand what’s happening in a system. Good name choices make it easy and natural to do the right thing—like expressive, well-chosen types, they lead you effortlessly to the terms you wanted to write.
Elements of Clojure
Mentioned above, this is one of my favorite books on the topic of computer programming. Zach has apparently made the PDF free in anticipation of his new book, Explaining Software
From the chapter on names:
A town named Dartmouth doesn’t necessarily sit at the mouth of the Dart River. If it did, and the river dried up, the name wouldn’t have to change. In the right context, ‘Dartmouth’ might refer to a crater on the moon. The sign was just a means of pointing at something.