https://larr.net/p/namings.html

Clicky

Hereby, all birds fly

all posts * short posts * books * anthology * PGP key * leave a
message
---------------------------------------------------------------------

Programmers and software developers lost the plot on naming their
tools

This section was labeled under, or is related to Programming

This post was discussed in HackerNews

In Dec 2022 I watched Richard Stallman's talk on the EmacsConf, it
was titled "What I'd like to see in Emacs". One of the interesting
points Mr. Stallman pointed out in this talk was "memorable names",
"I think every package that you [...] should have a name that helps you
remember what job it does. [...] We've had a tendency to give packages
names for the sake of pure wordplay or lack of obvious meaning". That
Stallman felt compelled to make this point in 2022 tells you
everything about how far we've fallen, even within the Emacs
ecosystem (known for its descriptive naming conventions, dired for
directory editor, eshell for Emacs shell).

There's an odd tendency in modern software development; we've
collectively decided that naming things after random nouns,
mythological creatures, or random favorite fictional characters is
somehow acceptable professional practice. This would be career
suicide in virtually any other technical field.

I remembered Stallman's comment lately when I had some difficulties
following my friend who was describing some situation in their
infrastructure. She was saying something like that: "We're using
Viper for configuration management, which feeds into Cobra for the
CLI, and then Melody handles our WebSocket connections, Casbin
manages permissions, all through Asynq for our job queue.", perhaps
only the last software in this statement was saying something about
what the package/software actually does, I spent couple of moments
trying to make sense of the names she mentioned, googled some of
them, and really while I'm doing that I remembered that I never had
to do this when interacting with any other fields: the Golden Gate
Bridge tells you it spans the Golden Gate strait. The Hoover Dam is a
dam, named after the president who commissioned it, not "Project
Thunderfall" or "AquaHold." Steel I-beams are called I-beams because
they're shaped like the letter I. Even when engineers get creative,
there's logic: a butterfly valve actually looks like butterfly wings.
You can tell how the name relates to what it actually defines, and
how it can be memorable. If you wrote 100 CLIs, you will never
counter with a cobra.

Same thing applies to other fields like chemical engineering, where
people there maintain even stricter discipline. IUPAC nomenclature
ensures that 2,2,4-trimethylpentane describes exactly one molecule.
No chemist wakes up and decides to call it "Steve" because Steve is a
funny name and they think it'll make their paper more approachable.

It was not always like that (I believe)

I read a lot into software history, and I can't really say that there
was an era of fantastic naming (even very experienced engineers made
some very silly naming) but at least some current was trying to make
some sense in the 80s; grep (global regular expression print), awk
(Aho, Weinberger, Kernighan; the creators' initials), sed (stream
editor), cat (concatenate), diff (difference). Even when abbreviated,
these names were either functional descriptions or systematic
derivations. Nobody named the copy command "Sparkle" or the move
command "Whisper."

Early programming languages followed similar logic: FORTRAN (Formula
Translation), COBOL (Common Business-Oriented Language), BASIC
(Beginner's All-purpose Symbolic Instruction Code), SQL (Structured
Query Language), I believe Lisp stands for list processing. The
pattern was clear: names conveyed purpose or origin. Somewhere around
the 2010s, a memetic virus infected software engineering. Perhaps it
started innocently, developers tired of boring corporate naming
conventions wanted personality in their open-source projects? maybe.
A few quirky names were charming. A database named after an animal?
Sure, MongoDB (from "humongous") at least has etymological connection
to its purpose, even if "Mongo" became the shorthand.

But we didn't stop there. We kept going. Now we're drowning in a zoo
of meaningless appellations where the connection between name and
function has been severed entirely. Probably pattern accelerated with
the rise of GitHub and startup culture. Everyone wanted to be the
next Google, a meaningless name that became iconic through market
dominance. Google could afford to build brand recognition through
billions in advertising and becoming a verb. Your MIT-licensed file
parser with 45 GitHub stars cannot.

The cognitive tax

Every obscure name is a transaction cost levied on every developer
who encounters it. When you see "libsodium," you must context-switch
from problem-solving mode to detective mode: "What does this do? Let
me check the README. Ah, it's a crypto library. Why is it called
sodium? Because chemistry? Because NaCl? Clever, I suppose." Now,
multiply this by dozens of dependencies in a modern project. Each one
demands tribute: a few seconds of mental processing to decode the
semantic cipher. Those seconds accumulate into minutes and effort,
then career-spanning mountains of wasted cognitive effort.

Imagine that you are to explain to a new engineer how is your
codebase structured, and the general architecture of some project,
and go through the dependencies you use to delegate some certain
tasks to and explain how they orchestrate together. Actually let me
put my friend's statement again instead: "We're using Viper for
configuration management, which feeds into Cobra for the CLI, and
then Melody handles our WebSocket connections, Casbin manages
permissions, all through Asynq for our job queue".

Now pause and actually process that sentence. there's a snake,
another snake, music, a mysterious proper noun, and... async-with-a-q?
Half your mental RAM is busy pattern-matching these arbitrary tokens
to their actual functions instead of focusing on the architectural
decisions being discussed. This is the equivalent of a cardiologist
saying "we'll install a Butterfly in your Whisper to improve your
Thunderbeat" instead of "we'll place a stent in your artery to
improve your cardiac output." Compare this to reading a scientific
paper in materials science. When you encounter "high-entropy alloys"
or "shape-memory polymers," the name itself conveys information. You
can make educated guesses about properties and applications before
reading a single word of description.

Some excuses I've heard of

I was told some of the following when I shared my concerns about
naming before, here's my thoughts of some:

  * "But memorable names help with marketing!"

    Sure, if you're building a consumer product. Your HTTP client,
    cli utility helper, whatever library is not a consumer product.
    The people who will ever care about it just want to know what it
    does.

  * "Descriptive names are boring!"

    Yes, and surgical instruments are boring. Boring is fine when
    clarity is paramount. This isn't creative writing class.

  * "It's just for fun!" Your fun has externalities.

    Every person who encounters your "fun" name pays a small tax.
    Across the industry, these taxes compound into significant waste
    [ ] And yeah, I know, this is not our biggest concern nor the
    biggest problem the industry is facing now, but sorry I had to
    talk about it. .

  * "All the good descriptive names are taken!"

    We could have used namespaces, prefixes, or compound terms like
    every other engineering discipline has done for centuries. We
    have the technology. But even if you can not do that, at least
    make the name has anything to do with the product, put a "DB"
    post-fix, do some word play like how "magit" does. If you
    couldn't be clear, you could have made it relatable at least.

The path forward

Whatever happened wasn't malicious--it was cultural. As programming
shifted from corporate mainframe work to the community builders.[ ]
Which was a good thing. , the social norms shifted too.

Thus, we need a cultural correction. Not regulation open source
thrives on freedom, but a revival of professional standards through
social pressure and education.

Name your library after what it does. Use compound terms. Embrace
verbosity if necessary. http-request-validator is infinitely superior
to "zephyr" when someone is scanning dependencies at 2 AM debugging a
production incident.

If you absolutely must have a cute mascot or reference, fine-make it
the project mascot, not the name. PostgreSQL has Slonik the elephant.
PostgreSQL is still called PostgreSQL. The elephant doesn't replace
semantic meaning.

Reserve the creative names for end-user products where branding
matters. For infrastructure, tools, and libraries, choose clarity.
Every time.

The next time you're about to name your project after your favorite
anime character, pause. Ask yourself: "Would a civil engineer name a
bridge support system this way?" If the answer is no, choose a better
name.

Our field deserves better than a zoo of random nouns masquerading as
professional nomenclature. Clarity isn't boring, it's respect for
your users' time and cognitive resources.

Footnotes:

^1

And yeah, I know, this is not our biggest concern nor the biggest
problem the industry is facing now, but sorry I had to talk about it.

^2

Which was a good thing.

---------------------------------------------------------------------

Some works I recommend engaging with:

I seek refuge in God, from Satan the rejected. Generated by: Emacs
30.2 (Org mode 9.7.34). Written by: Salih Muhammed, by the date of:
2025-12-11 Thu 18:27. Last build date: 2025-12-11 Thu 21:29.