alt Hacker NewsProgrammers and software developers lost the plot on naming their tools
Comments
> 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.
If you asked someone unfamiliar with unix tools what they thought each of these commands did, diff is the only one which they would have even the slightest chance of guessing. It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name.
> This would be career suicide in virtually any other technical field.
This article would certainly disagree with you:
https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Def...
> the Golden Gate Bridge tells you it spans the Golden Gate strait.
Is that even a meaningful distinction? Does anyone think, "Gee, I'd really like to cross the Golden Gate strait?" or do they think "I want to get to Napa?".
> The Hoover Dam is a dam, named after the president who commissioned it, not “Project Thunderfall” or “AquaHold.”
It was actually called the "Boulder Canyon Project" while being built, referred to as "Hoover Dam" even though finished during the Roosevelt administration, officially called "Boulder Dam", and only later officially renamed to "Hoover Dam".
The fact that Herbert Hoover initiated the project tells you nothing meaningful about it. Would "Reitzlib" be a better name than "Requests"?
> If you wrote 100 CLIs, you will never counter with a cobra.
But out in the real world, you could encounter a Shelby Cobra sports car, Bell AH-1 Cobra chopper, USS Cobra (SP-626) patrol boat, Colt Cobra handgun, etc.
> 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.
When you open your medicine cabinet, do you look for a jar labeled "acetylsalicylic acid", "2-propylvaleric acid", or "N-acetyl-para-aminophenol"? Probably not.
It's a bad sign when all of the examples in an article don't even agree with the author's point.
Worst example: homebrew nomenclature
Typical docs sentence:
> What does “keg-only” mean? It means the formula is installed only into the Cellar and is not linked into the default prefix.
I believe strongly in this counterargument:
https://medium.com/better-programming/software-component-nam...
Small summary: external identifiers are hard to change, so projects will evolve such that they are not accurately descriptive after time.
(Less discussed there, but: In a complex or decentralized ecosystem, it's also the case that you come across many "X Manager"/"X Service"/"X State Manager"/"X Workflow Service" simultaneously, and then have to rely on a lot of thick context to know what the distinctions are)
> “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.
——
It sounds like the author doesn’t view themselves as a consumer in this relationship, that they are immune to marketing, and that what they are advocating for isn’t just another marketing tactic. I’m not sure if any of those are true.
My experience with areas that use functional names to describe things is that you end up in a sea of acronyms (the functional-based names are a mouthful!) and you end in an arguably worse situation (did you say ABDC or ADBC, those are two completely different things).
> This would be career suicide in virtually any other technical field.
The cognitive load is unavoidable and in some ways worse in industries with highly technical names.
At one point in my career I was an engine calibrator at a large automotive OEM. Our lexicon included physics industry terms (BMEP, BTDC, VVT, etc), a large software package where every variable, table, and function was an acronym (we had about 75k tunable parameters, each with an acronym), and all the internal company jargon and acronyms you'd expect in a large corporation. But every name was as technical and functional as the author would desire.
During my first month I was exhausted. I would doze off in afternoon meetings or pass out in my car as soon as I pulled in the driveway. I finally mentioned this to a more senior coworker and his insight was that my brain was working overtime because it was busy learning another language. He was entirely right! The constant mental load was a very real and tangible load. He relayed an anecdote when he went to S. America on his honeymoon and despite him and his wife having taken ~4 years of HS/college Spanish the mental work they had to do to function basically nixed half the daily activities they had planned due to exhaustion. That was what I was experiencing.
The idea that more technical and specific names reduces mental load does not track with my experience. The complexity is intrinsic not incidental and I don't think it has much to do with the specific names chosen.
Sometimes I am baffled at what gets onto the frontpage at HN, reminding us all that the people who vote stories and the people who comment on them are less of an overlapping group than you might think. I can understand the desire to have names that are more descriptive, but to claim we have "lost the plot" while holding up names like "awk" is contradictory at best. It sounds more like this person just had a personal vendetta against cute sounding names, not against the names being uselessly non-descriptive. In my opinion, the way this post is framed at the outset is misleading.
— This comment brought to you via Firefox, which obviously from its name, is a web browser.
>“Descriptive names are boring!”
>>Yes, and surgical instruments are boring.
I'm absolutely certain that this person has never been (awake) in a surgery suite because all of the tools people use have eponymous names.
There are a billion little grabbers that all have silly names like Adson, Allis, Babcock, Kocher etc. which are all meaningless until you just know what they are. And don't you grab the Mayo scissors when they ask for Metzenbaum. In med school we had a flashcard deck that just had a picture of the tool and what it is called on the other end.
In the end, I think the author has a point, but then doesn't really make it that well. I think using awk as a good example is a bit silly. diff is a good one though!
Ok man, now give me a moment, I need to administer my weightloss weekly injection of L-Histidyl-2-methylalanyl-L-alpha-glutamylglycyl-L-threonyl-L-phenylalanyl-L-threonyl-L-seryl-L-alpha-aspartyl-L-valyl-L-seryl-L-seryl-L-tyrosyl-L-leucyl-L-alpha-glutamylglycyl-L-glutaminyl-L-alanyl-L-alanyl-N6-(N-(17-carboxy-1-oxoheptadecyl)-L-gamma-glutamyl-2-(2-(2-aminoethoxy)ethoxy)acetyl-2-(2-(2-aminoethoxy)ethoxy)acetyl)-L-lysyl-L-alpha-glutamyl-L-phenylalanyl-L-isoleucyl-L-alanyl-L-tryptophyl-L-leucyl-L-valyl-L-arginylglycyl-L-arginylglycine
> 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'm charmed by the lack of truth in this beautiful sentence. Top of mind for me, at least.
> 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.
I felt a little guilty at first, I maintain a project called Wimsey (it's a data testing library but you couldn't guess that) and at work my team regularly enjoys fun/silly names.
Trying to defend myself, I was thinking about various logical responses to this article: non-descriptive names don't become out of place when a projects goals drift; descriptive names will lead to repitition; etc.
If I'm honest though, I think I just like software to have a sense, even a tiny one, of enjoyment.
The software I use everyday, like Cron (named after a greek god of time); Python (named after a comedy act) and Zellij (names after a tiling craft) all have fun, joyful names that tell me someone loved and cared about these projects when they built them.
I need to learn these tools beyond just "x does y category of thing" anyway, so I don't mind learning these names. And it makes software engineering just a bit more fun than using "unix-scheduler", "object-oriented-scripting-lang" or "terminal-display-manager".
I love working in a field where people are passionate about their craft. Stern professionalism doesn't sound like something I want to trade that for.
It's a human trait to name the things we love, that's the exact reason why pets typically have names like "cookie" and not "brown-dog-2".
I had to discover this myself. when I first started working on personal projects on my PC, I'd give each of them some whimsical name, usually a pun or play on a quote from a tv show or song lyric. then in a few months time I'd come looking for the project and have to spend five minutes scrolling through a bunch of esoteric word formations and random half sentences trying to remember what whimsical mood I was in when I made the project. now I just name everything whatever I think I'm most likely to remember in 3 months. I do find it a little sad, losing some creativity and colour, so maybe one day I'll make a tag/shadow title system so I don't need directly descriptive names
> "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".
But before those silly names came up, every company used their own three letter abbrevations for their tooling, which was not much better. They had descriptive names, but using the abbrevations only didn't help, and you needed a company wide dictionary. Like "We’re using CMT2 for configuration management, which feeds into CCM for the CLI, and then WSM handles our WebSocket connections, PM manages permissions, all through AJQ for our job queue."
I still think ICQ was the greatest application name ever.
Nondescriptive names are not necessarily wrong or impeding. The author mentions science, yet STEM is filled with nondescriptive names: we have "Pythagorean theorem" instead of "right triangle sidelength theorem", "Newton's method" instead of "iterated tangent root-finding", "Lambda calculus" instead of "abstraction-application evaluation". Although they are not whimsical, these terms mean nothing to a first-time reader.
The problem with descriptive names is that they start descriptive but then become proper nouns. At a former employer in the Fortune 100 outside the software industry, everything started with a descriptive name, that then became an acronym. And as every project and tool inevitably developed its own idiosyncrasies, the descriptive name pretty soon didn't tell you anything useful about the project at all.
It is an unavoidable reality that knowing something's name gives you very, very little information about what that something is. That's what sentences are for.
> 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 worked in finance – we gave our models names that endeared us to them. My favorite is a coworker naming his model "beefhammer".
I strongly disagree with this: calling your thing that serves webhooks “webhooks” or “webhook-service” sounds nice and neat when you’re looking in a repo list but you immediately impose a tax on everyone in the org: now everyone in a conversation has to distinguish between “webhooks” as the proper name of a particular service and “webhooks” as the name of a particular pattern. Multiply this by all the various components of a modern software ecosystem, and you turn your companies infrastructure into a private language piecemeal and, what’s worse, it’s a private languages outsiders and newcomers think they understand and so they often take much longer to discover what the actual services are.
> programming shifted from corporate mainframe work to the community builders > which is good
but then:
> Our field deserves better than a zoo of random nouns masquerading as professional nomenclature
Okay? So is this professional nomenclature or the work of community builders?
I think: everyone should code, it should not be an elitist profession, we don't need to all accommodate busy professionals, i'm fine with corporate users having to say my stupid package name at work.
> Your fun has externalities. Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste
Someone please get this guy a bong rip.
If the community followed the author's guidance, we would have names like "Generic LLM wrapper 690" ("GLW690" if following the early programming language conventions.) or "Github clone with a different ideology 11"
I read an article linked on HN once (can't remember what it was) that recommended giving totally meaningless names to monoliths. The point being that one should not use the name as a crutch to decide what should or should not go in the service.
So at my last job, we called our monolith anubis. It always brought joy when someone asked for an explanation.
> 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.
This so isn't important, but this just isn't true at least in chemistry. Plenty of molecules have names that aren't IUPAC based, but instead are based on prefixes/suffixes that are common to the field (more in pharmacological chemistry but not just!)
Its interesting how early programming languages are mentioned as having proper names. In the 60s we went from BCPL to B to C. B and C are not descriptive at all. Should they have been named "operating systems language" or "portable Unix language" instead? I also fail to see how AWK is a well named tool according to these metrics. The initials of the creators dont tell you anything about what it actually is or does.
Forget about tools, in most part of the world, the name programmer and software developers like to call themselves namely software engineer is not even considered part of engineering professions.
That's why you find most of software engineering department in Computer Science Faculty or School, not in the Faculty of Engineering.
I'll die on the proverbial hill that the absolute worst instance of this has always been GIMP, which could have perhaps eaten Adobe's lunch MANY years ago.
It was and perhaps still is, a solid competitor to Photoshop, but any unfamiliar grownup is, quite reasonably, going to never ever ever trust anything to do serious work with a name like that.
By this standard, ChatGPT is an excellent name: it's a generative pre-trained transformer that chats with you.
Might as well just name it after the last name of the author. Like how physics has the Maxwell equations, we’d have the Torvalds Operating System.
That glorious day when I explained to my boss what wiki is and that we should have one internally, he fired "viki" into google, with smoothly honed muscle memory clicked first result..and got full screen of poon.
>http-request-validator is infinitely superior to “zephyr”
Is it though? How are you going to differentiate between 10 different variations of http-request-validator repos on GitHub? I think both have their downsides, but making the name super generic sounding is arguably worse. What I don't like about names like zephyr is that they're purely marketing-driven; people end up picking a zephyr over a http-request-validator purely because the name is sounds "cool" to them, even though http-request-validator might actually be the better library. And don't even get me started on people naming their projects random Japanese words.. it's like the equivalent of nicknames that Thai people use, which are just random English words like Ice Cream or Thank You.
Maybe the happy medium is, like you said, names that contain a hint as to what they do, like Actix (actor model). But TBH you kind of still have to look it up to know what it does, there's no way you're just going to infer that. Maybe later on it helps you remember what it was for though.
I think if a project name is easily googleable, it's a good name. If I see "generic-tool-name failed" in the logs and can't immediately find what that thing even is, because I get lots of irrelevant search results, it's a bad name. This can happen with both descriptive and cutesy names.
I think the author is ignoring the difference between Branding and several other categories, like technical terms and their common names.
The adjustable wrench is named straightforwardly, but most English speakers know it as the monkey wrench. In some European languages its name translates to "French wrench" or "the French" (as in: French person), in others it's "English wrench" even though those two were originally just variants of the adjustable wrench.
Point is, all those goofy names are brands that may or may not stick around for longer and the terms for what they actually do are more descriptive.
My favourite example: BlueJeans. A videoconferencing platform. Why is it named like that? We might never know, but most likely partly to stand out, but there's a clear distinction between the brand name and the more descriptive terms used to tell what it does.
If you didn't already know, what do you think a tool called "emacs" does?
> 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.
I'm creating a dotfiles to remote SSH session tool in shell. At first, I wanted to call it "sship", but that name was already taken. Something like "ssh-dotfiles-carrier" felt too long for a command, and abbreviating it to "sdc" would lose the meaning.
So yes, I eventually named it "shitt-p" (character of Hitman Reborn!), since I wanted it to relate to "sh"...
Unfortunately this article misses the worst failure of naming: name collisions.
We should all copy from the Haskell community. Instead of coming up with a random name like "append" for a List function, we should appeal to our deep intuition of monoids and use the much more intuitive "<>".
Yeah, this is a bit relative. Use microsoft tools/products (especially cloud/office) that came out in the past decade and you'll appreciate every other naming pattern.
My subjective view is that names should be exotic, flamboyant, unique and generally wild when it comes to tools. sticking your company's name as a prefix into everything (or the flagship product's) is confusing and only hurts you.
"First we have to build a Bingo service. See, Bingo knows everyone's name-o..."
- 'Microservices' sketch by Krazam
Descriptive names are great until the thing you built starts evolving and doing more or less than the description and then is way more confusing that calling something somewhat general like my favorite of all time: 'Conformity Beaver'. The same goes for teams. Mythical creatures are good because they are fun and also allow the team to evolve its mandate and custodianship and may also help with Conways Law.
Why is Go a very silly name and not Python, C, Rust, or literally any programming language name?
My old company Canva, was pretty good about this and I'm bringing that to the culture at my current place.
Krazam has excellently parodied this unserious naming indulgence of programmers[1]. "See, Bingo knows everyone's name-O. So we get the user ID from there." Racoon, Wingman, EKS (Entropy Chaos Service), RGS, Barbie Doll, Ringo-2.
I really gotta hand it to "wget" for picking a good name for a program that gets things from the web.
I think there should be some kind of a tax or a fine for anyone who comes up or even suggests a new acronym. Regardless of the field. While I do agree with the article on some level, I still think even a randomly picked word from the dictionary is better than YAA (Yet Another Acronym).
Yep. Just did a reimage update to Fedora 43, got errors about 'ptyxis' in some shell scripts. Wat (wipes desk and keyboard)?
Oh, it's the graphical terminal program (alternative to 'gnome-terminal'). Well, um, ok.
However, I will concede, after more digging as to why (as it rankled), that there was a "have to choose a unique name" issue there (even leaving aside trademark issues). I'm resigned (so I suppose signed up) to deal with residual issues that crop up going forward.
I love to mock '*ly.com' names for almost certainly doomed enterprises, but I get that at least it wasn't already taken.
A bit tangential but I was going to make a post of my own on naming with the problem of "filenames"
so many times I download something and the filename has nothing to do with the file or it's too much of an abbreviation so when I go to look for the file it's hard to find or if I come across one of these files I have no idea what it actually contains
The article mentions that things were fine until around 2010 when developers collectively lost their minds. So what’s special about 2010?
It’s about that time that everything needed a website with a domain and all the domains were gobbled up by squatters. Also people were inventing new words looking for the fewest possible syllables for SEO and marketing.
The cognitive tax is a real problem. Using random cutesy names, there is no obvious behavior boundary. Does authentication go in the SnufBux module? Or the Farfrumstable service? Who knows? Without obvious language clues to handle a new concept, any new functionality will get strewn across these internal boundaries. And why not - they have zero semantic meaning anyway! Sloppy names encourage sloppy programming.
> http-request-validator is infinitely superior to “zephyr” when someone is scanning dependencies at 2 AM debugging a production incident.
The "Zephyr" that I knew about was a notification system for workstation clusters on a LAN, written at the MIT Athena project. You'd announce something on it, and the info would spread through the network as if by a gentle breeze. See: https://en.wikipedia.org/wiki/Zephyr_(protocol)
I do recall there was an experimental study in the 1980s (Hartwell, Landauer, and Gigliotti iirc) showing that this naming stuff doesn't matter. This exact same debate was going on back then. The study refuted Don Norman's "The Truth about Unix" paper which claimed that Unix commands ("rm", "mv", etc.) were too hard to remember.
I agree with the sentiment, though the argument could be made better. It’s not really about good names being descriptive, nor about memorable mnemonics. It’s that modern naming styles tend to overload random English words for no good reason, but just to be cute (which I don’t consider a good reason) or to be evocative of something which it isn’t. One issue with that is that you might have very different connotations evoked by the word, that clashes with the software. And conversely, if you have to use the software regularly, it now encroaches into the semantic space of what you otherwise associate with the word. I’d like my software, and hence its name, to be its own thing, thank you very much.
That is one thing i like about the Julia package ecosystem. The general Registry (where package metadata is stored and where you go to register a new package), recommends using explicit names over short acronyms. For example, DifferentialEquations.jl is a package that does differential equations in julia (recognizable via the .jl suffix). What does Garlic.jl do? Exactly, garlic (the vegetable) modelling.
GNU's version of Yacc is called Bison. Pine Is Not Elm (even though that was never an official acronym). UNIX was UNICS which was a pun on MULTICS. I couldn't for the life of me tell you what dd stands for. nano is a copy of pico which was the "PIne COmposer". Postfix is a completely opaque portmanteau of post (as in mail) and "bug fix". C++ is "C incremented", and C is the successor of B, which is the successor of BCPL.
Developers haven't "lost the plot", we never had it in the first place.
Inversely, Clang, LLDB, jq, fzf, loc are modern projects perfectly in line with the author's notion of a good name. "mise-en-place" is the perfect metaphor for what mise does.