Programmers and software developers lost the plot on naming their tools

FORTRAN (Formula Translation)

I would have literally never guessed this in a quintillion years. It's effectively whimsical, just for 1957's whimsy instead of 2025's.

When you encounter “high-entropy alloys” or “shape-memory polymers,” the name itself conveys information.

"shape-memory polymers" is a category of polymers, the same way "configuration management" is a category of tools, not a product. If you look at the products sold by a shape-memory polymer manufacturer like Covestro AG, you get a list of random sounds like "Apec", "Bayblend", "Makrolon" etc.

I'm not claiming that this article is entirely about aesthetics, but it feels preoccupied with the aesthetic of Serious Engineering. Names in other disciplines are often dubiously mnemonic, and you still need domain knowledge to understand what they actually are.

(Compare with the ethos of Comfy Software (lobsters), which I am on the record as vibing with more.)

We could have used namespaces, prefixes, or compound terms like every other engineering discipline has done for centuries.

One problem is that anyone can grab the name http-request-validator. What if it's not fit for purpose? What if I want to try an alternative approach that might not be upstreamable? What if I don't get along with the author? We could namespace packages, à la GitHub, e.g. jdpage/http-request-validator, but when you're scanning a list of dependencies this is even less memorable than a cute name, especially if someone has authored multiple packages.

ADDENDUM: It's probably relevant that software engineering descends from computer science, which is a branch of mathematics, which has a history of whimsical names.

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.

Really? Physicists come up with particles called “quarks” (a made-up word from Finnegans Wake) that have properties like “charm” and “strangeness”. Mathematicians have “imaginary” and “perfect” numbers, and generic words like “group” and “ring” refer to very specific concepts. Biologists name species after Latinized in-jokes (there's a beetle named after Gary Larson), and there are a lot of genes with silly names like sonic-hedgehog. Astronomers have been naming stuff after mythological creatures for millennia. There’s a desert plant called “Boojum” and a cryptographic construct called a “Snark”, both from Lewis Carroll.

The pattern was clear: names conveyed purpose or origin.

Even if this was true(¹), how does this help lowering the cognitive tax? C coming from B, itself coming from BCPL doesn't help me if I don't already know about C, because it's not obvious. How does awk being the initials of its creators help me identify what I can do with it? Same thing with COBOL or FORTRAN: unless the full names are used, their speciality isn't obvious. And even then, the names are very generic.

(¹) I don't think it really is. What can you do with a Macintosh? Or with Windows? What's Ada, is it a language to automate looms? That curses library sounds dangerous.

Just responding the the bullet list

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.

Nope, you’re building a consumer product if you aren’t building it for yourself. The fact that companies or other projects are the users does not mean they aren’t consumers

“Descriptive names are boring!” Yes, and surgical instruments are boring. Boring is fine when clarity is paramount. This isn’t creative writing class.

The purely descriptive names were taken 30+ years ago, and even then most of the names that “indicate what they do” quite frankly do not. “Emacs” is not a name that says it’s an editor, nor vi or vim, et

“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.

What actual cost is there? This just sounds like elitism pure and simple

“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 not be clear, you could have made it relatable at least.

Different products with essentially the same name, sans spelling, capitalization, punctuation, implied phonetics are actively worse for everything

Sure, whatever buddy.

Yes and no. I can understand why a self-respecting software professional might run away from a tool like ChilliCream Hot Chocolate based on the name alone. However, I’m not sure that more projects with names like PostgreSQL will clear things up. It’s a double portmanteau, the origins of which are not immediately obvious—I doubt anyone fires their computer up in 2025 and says, “Now, where can I find my Ingress successor with SQL support?” It only feels obvious and familiar today because the tool itself is obvious and familiar. I doubt that if PostgreSQL has been named Slonik it would be any less popular.

Another road one could go down is Objective C style naming like:

HMCharacteristicValueLockMechanismLastKnownActionUnsecuredUsingPhysicalMovementExterior

or:

CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter

That way lies a culture of Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz, which is fine in moderation but difficult to read in excess. One might argue for more mathematically based words like the good old days, but even the ones we already have (function, isomorphic, scalar) are really just metaphors that mean something fundamentally different in math.

I think it's possible to make an argument for intelligible names, but that the claims around recency are essentially ahistorical.

Using the post's own motivating example of Richard Stallman: one of GNU's most central libraries is named libiberty seemingly solely so that the GNU folks could feel clever while writing -liberty as a linker argument.

The middle ground here is non-dry/academic names that also convey meaning. Examples include python's "requests" library and rust's "chrono" library. These are both memorable and related to the functionality they provide. IMO this is preferable to the very dry alternatives ("httplib", "datetime"), but not always possible to achieve.

This starts with an anecdote from a GNU/emacs conference.

I'm of two minds with this - for one I love whimsy and if you can get a good name-sake for your open source tool then by all means go for it. But if I'm working on internal tools for work we tend to opt for very descriptive names over pet names. These tend to become acronyms and then we have an internal shorthand to use for those tools everywhere.

A good example of trying to remember names is all the different tools that work with Grafana - including the tools made by Grafana themselves. Trying to remember Mimir, Prometheus, Tempo, etc and what their purpose is and how they fit into our monitoring and observability stack is a lot of metal load. Of course, this would likely change in my mind the more I talk about and use these tools.

A counter example is all the AWS products. If you're not in the AWS world saying something like "We publish the container to ECR an then deploy into ECS on Fargate behind an ALB." All of those names (save for maybe Fargate) are very descriptive names but also end up lost in the sauce of acronyms.

So I guess my point is that there is a balance between pet names and extremely literal technical names and the real problem is one's exposure to either.

If there's any other field that would be even worse about this than us, it would be pharmaceuticals.

(Try having a game of "Antidepressant or Tolkien Character". It's surprisingly hard - even for an antidepressant user who used to be a huge Tolkien fan.)

Naming is famously hard. I had to go up and down the entire etymology tree multiple times, not finding a suitable (easy to pronounce and slightly comprehensible) word that isn't already taken. Find me some good names for a (lightweight) markup language or a programming language. Given the number of programmers out there, the entire namespace, so to speak, is saturated, with all low hanging fruits been taken away. It'll only get more difficult in time to come. Either you give up on clear and accessible names or accept the possibility of name collisions.

English as a second language was difficult for me, for I started with the formal, academic register (which I still continue to use to this day) and learnt more about the culture later. Whimsical names, or rather their underlying connotation, was wholly or partly inaccessible to me and I treated them like numeric identifiers. Thus, in remembrance of my past self, I'd not like to impose the same onto others. So, when you do use such names, please explain the connotations for the non-native speakers out there when it's not entirely obvious.

As the author puts it, the cultural shift has already happened and it wont be practical to enforce any such norms, now or later. We can only hope to transfer such cultural, tacit knowledge to future generations.

I think the next big language should have two-tier package manager namespace and new packages shall be created in 2nd tier and only get promoted to a descriptive name if they are the most depended upon in that category for at least 5 years.

Early adopters tend not to be that great at making good packages, but they do exhaust the namespace very rapidly.

Meh. If I can't have fun coming up with a name for a project I wouldn't even start it. I like programming and I like having fun while doing it.

---

To probably the chagrin of the author I almost always start by attempting to generate a name from a recursive acronym.

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),

wordplay is infinitely better than the author's initials

“What I’d like to see in Emacs”. One of the interesting points Mr. Stallman pointed out in this talk was “memorable names”

on the contrary, I wish the (neo)vim community emphasized on wordplay names like the emacs community does - there are very few people other than tpope who do this

I've grown to mostly not care about this. There are some obviously bad names like utoipa, which hurts my brain whenever I see it, but ultimately the author was just having a bit of fun. The examples in the article are mostly innocuous in my opinion.

However: I wish we would stop naming things after real people or real names unless it's someone the author knows. I don't care about Linux, Debian, or MySQL, but abstractly naming your software Hugo, Jenkins or Julia just feels out of place.

Expectation: Open Asset Import Library

Reality: https://github.com/assimp/assimp

Well I certainly think, all things being equal, that a self-documenting name for a project is better than an irrelevant name. So, with that agreement out of the way, I'll say that I think it's complex and subjective and overall my experience doesn't seem to be the same as the author's.

I think naming a public project "http-request-validator" probably swaps out one type of tax for another, depending on hard-to-predict factors. Which of the gazillion validators am I referring to? Do I even have the right one in my dependencies? Or is it some other project with the same name built by somebody else?

I haven't personally experienced older software engineering culture to be committed to self-documenting names, nor other technical fields really. When I started programming, the first few languages I learned were C, C++, and BASIC. Other less-popular options at the time were Pascal, Ada, Eiffel, Smalltalk. None of these are self-documenting... not even "BASIC" IMO because learning the acronym is more taxing for me than just learning that BASIC is a programming language.

Also, there's the danger of coupling the name to a behavior that will change. Unix is a multi-user operating system which makes it a misnomer, right? Assuming we've already paid the tax to learn the meaning of the name, a misnomer is likely not considered better than an irrelevant name and arguably could be worse in some cases. And actually, its name was "Eunichs" or something like that at first, right? That's mighty whimsical and happened over half a century ago. The follow up within the same culture was named "Plan 9" after a bad movie.

Another thought I have is that I think attractiveness also matters outside of commerce, too, as folks struggle to get adoption for their projects. "http-request-validator" is 10 syllables and making it unambiguous would require more syllables. "VineJS" is a request-ish validator I know of and has a meaningless (to me) name that is 3 syllables (or potentially 1..) It just feels subjective and hard to predict to me. And at a certain point one has to commit to a name, subpar as it might feel, and move forward with things other than naming. And getting back to misnomers, what if "http-request-validator" evolves to be more general purpose like "zod"? Do I keep the name or do I change its name to "general-validator" and start various aspects of the adoption slog over?

So I think the author's naming preferences are totally valid. Just not really in alignment with my personal experience of either current or past project names.

This hit home for me. I realize I need to go to an about page too often just to see what something is, whether on hearing about it in passing, or wondering what that forgotten thing in my homebrew update list is.

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.

The author seems to lament the lack of seriousness and professionalism in software naming yet chooses to end each blog post with "I seek refuge in God, from Satan the rejected." Maybe it's their "social norms" that need "shifting" rather than the community at large.

I also prefer names making some sense in context of what the projects do. Maybe there is middle-ground in adding short descriptive subtitles to fancy naming.

If it was obvious what this, or libdjb, implements, it would have the most GOATed name ever: http://www.fefe.de/libowfat/ ;) The pun being you compile against lightweight library with -lowfat ;)

I also dislike modern names, and it really sucks, because to me Astral is maybe the best, but has the worst names. One can imagine ruff being rough on your code (with love) but uv? And ty sorta makes sense as an abbreviation of type, but I got it off a podcast transcript it's pronounced t-y. Why?

When the descriptive names are taken and the fantasy-figure names are weird and/or taken, what remains at the bottom is this. Everyone should do their best with coming up with mnemonic names, so it is closer to creative writing than the article implies.

I care more about this, but mostly for internal project names. My previous place had named its legacy systems after Italian fashion brands. On-boarding new people is harder when names aren't somewhat connected to what they do, especially when they're still learning how all the boxes and lines connect together.

Reminds me of the recent struggle I had while reading through the list of projects by UnJS.