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.
> I couldn't for the life of me tell you what dd stands for.
Data(set) Definition. But that name does not make any sense whatsoever by itself in this context, neither for the tool (it hardly "defines" anything), nor for UNIX in general (there are no "datasets" in UNIX).
Instead, it's specifically a reference to the DD statement in the JCL, the job control language, of many of IBM's mainframe operating systems of yore (let's not get into the specifics of which ones, because that's a whole other can of complexity).
And even then the relation between the DD statement and the dd command in UNIX is rather tenuous. To simplify a lot, DD in JCL does something akin to "opening a file", or rather "describing to the system a file that will later be opened". The UNIX tool dd, on the other hand, was designed to be useful for exchanging files/datasets with mainframes. Of course, that's not at all what it is used for today, and possibly that was true even back then.
This also explains dd's weird syntax, which consists of specifying "key=value" or "key=flag1,flag2,..." parameters. That is entirely alien to UNIX, but is how the DD and other JCL (again, of the right kind) statements work.
I had remembered it was "convert and copy", but cc was already taken by the c compiler so they shifted it down a letter. That might have been apocryphal.
You know, this is true. And I've read any number of "you should never use dd, use this instead" articles over the years. But man, do I love me some dd.
dd is the software equivalent of removing the riving knife from a table saw.
Then again, I get very paranoid when I write software that has to delete arbitrary files recursively. One bad string gets in there and it's a very bad day.
I feel obliged to point out that C++ is C postincremented, that is to say it has the same value as C, but after you read it C gets incremented. The metaphor is flawless.
By the same token, the sharp sign in C♯ is two plusses put together, and represents going a (half) step above C. Also, a minor second is one of the most dissonant intervals in western music, which is also a brilliant metaphor for how well C♯ meshes with C.
Even GNU is a recursive acronym, Emacs a convoluted one... What's Perl, Python, Java... all about? Remember how JavaScript was named? Don't mention Go (go-lang) or Pascal... Git, Mercurial, CVS anyone?
Then Gimp is also a great name, right? GNU-is-not-Unix Image Manipulation Program: immediatelly obvious what it does as soon as you learn what the acronym stands for.
Or Gtk even: Gnu-is-not-Unix Image Manipulation Program ToolKit (later changed to refer to Gnome instead of Gimp I believe).
Java was originally called Oak but its creator because he could see an oak from his office, but marketing people at Sun thought Java would be more catchy. Yes it's named after coffee beans, but it has no relation whatsoever to the language or the way it was created, it's just a marketing name.
I can totally see how that was an obvious decision in the 90s, the coffee shop craze was just taking hold in America, and it was such an exciting and fashionable thing to do to sip espressos and lattes.
Pascal is probably the most sensible name, as far as traditional naming schemes go. Names after Blaise Pascal, mathematician and one of the two inventors of the mechanical calculator. Pretty fair association and tribute.
Git as a name is our daily reminder that pre-mainstream programmers were rebellious against the mainstream (to put it as generously as I could) before corporate interests took over. but i encourwge you to look up that story yourself.
It would be funny if I did not run GNU/Linux as a daily driver since 1998: Plan9 did look interesting too, and compared to GNU/Hurd, it was certainly in a better shape.
(Even Solaris, *BSDs already started including GNU tools, compilers...)
The article even refers to AWK as being the initials of the authors. And posits this as "reasonable"?
Naming is hard, not least because "a million" new projects are spawned every day. And if you're going down a path of "rule the world" (even in a niche like infrastructure) you start by getting a .com domain, so choices are limited.
I thought the more common mistake with dd was picking the wrong disk to write to (especially when using /dev/sdc type naming instead of /dev/disk/by-id/whatever naming). Flipping source/dest and overwriting data is a problem I associate with the tar command.
In the same vein, my recollection is reading that the X windowing system is called X because it's the letter after "W", which was the original choice (because it's what the word "window" starts with), but it was already taken, so they went with X.
It looks like X was deliberately chosen to denote succession of W, not clashing with it:
"The name X derives from the lineage of the system. At Stanford University, Paul Asente and Brian Reid had begun work on the W window system [3] as an alternative to VGTS [13, 221 for the V system [5]. [...] We acquired a UNIX-based version of W for the VSlOO (with synchronous communication over TCP[24] produced by Asente and Chris Kent at Digital’s Western Research Laboratory. [...] It was also clear that, although synchronous communication was perhaps acceptable in the V system (owing to very fast networking primitives), it was completely inadequate in most other operating environments. X is our “reaction” to W."
I think I sort of meant the same thing, but my wording might have been unclear. Essentially, there already was a W, and they were making something new, so they picked X.
The only thing that's different between the era when Bison as named and now is the proliferation. There is vastly more shit in open source with the cute names. Back then, one person could keep all the cute names for everything related to C and Unix in their head.
>The only thing that's different between the era when Bison as named and now is the proliferation. There is vastly more shit in open source with the cute names.
I personally think that's a pretty good idea for coming up with better names instead of cute names now.
How do you discriminate between 2 different things that ostensibly have similar features, but do it in different ways without getting very large names? What if you modify software or just part of it to make it something distinctively new, should it keep the name or add to it? What if I revert that non-trivial feature and add a different non-trivial one. Now what is it?
I would hope the author realizes the core counterpoint when re-reading "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" - because the real names, are the roles the tools play. The implementation name is incidental and amorphous, since you can make wild changes to software, rendering the name without much utility beyond a project label. Project labels are necessarily opaque, for the same good reasons software is. The ideals are more important than the details. They are a conflux of interests and plans, not a market label. If market labels were fixed to functionality, the world would be worse off for obvious reasons of practicality and marketability. Ironically, Stallman is completely comfortable with PostgreSQL which is semantic context adjacent, charitably. It describes a small element of the project (a synthetic SQL syntax), not the project itself.
I remember writing a function to convert a string from snake case to camel case and calling it `humpify`. And another that would take a string and locate the constant with that name called `constantinople`.
But then, this is ruby and it's known for its unusual naming. Plus both also had sensible/boring aliases and they were for internal use only.
eh, in 2025 SEO ( Whatever the jargon is for LLM) is as important or perhaps more important so that you can search and find documentation and issues etc
I agree we never had it in the first place, and that it ultimately doesn't add up to much. It seems like just a familiarity problem.
If I'm diagnosing something at 2AM, I don't care whether my database queries were written with Zapatos or PG-ORM, even if the latter is clearer. As long as you use the tools, you know what they do.
Nano was originally TIP which stood for "TIP Isn't Pico" but was later changed to Nano so as not to conflict with another Unix utility called tip [0]. Presumably nano was chosen as the metric prefix next larger than pico.
Personally, I'd prefer choosing a random string of 3-8 letters for command line tools. At least that would be better than naming programs using generic names (Keep, Bamboo, Chef, Salt) which leads to all sorts of name collisions.
From the article:
> This would be career suicide in virtually any other technical field.
The mascot for an $8.8T dollar (supply side) software industry, larger than Google, Microsoft and Apple combined, is a cartoon penguin [1].
"never had it in the first place" is absolutely correct.
> "never had it in the first place" is absolutely correct.
To be clear: I didn't mean to imply this is a bad thing.
GNU's Not Unix, Pine Is Not Elm, TIP Isn't Pico all share one important characteristic — their audience is expected to know what Unix, Elm, Pico are, and saying "X is not Y" implies "X is specifically, deliberately an alternative to Y, in the same style as Y".
If you know what GNU and YACC are, you probably don't need to be told twice that "Bison" is GNU's YACC implementation — the pun makes it instantly memorable.
One of my personal favourites is Ubuntu's version naming scheme. The "alliterative animal" form is highly memorable, and gives you two different words to latch on to, either of which is enough to uniquely identify a version. The fact they're alphabetical also makes it easy to check which version is newer (Letter collisions happen on a 13-year cycle, which makes it highly unlikely to be a source of confusion).
> their audience is expected to know what Unix, Elm, Pico are
Of course, the context for these references are all kind of anchored in the 90s. Someone first discovering Bison in the year of our lord 2025 is unlikely to have the foggiest clue what YACC was...
> 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.
Yeah this definitely falls into the category of "I use them so they feel natural", there's nothing amazing about those names.
The underlying problem is that you now run into so many named things (utilities, libraries, programs, etc.) in a day and they all have to differentiate themselves somehow. You can't name every crypto library `libcrypto` for obvious reasons.
You can, but then the names get needlessly long and one of the things we generally like (especially for command-line programs) is names that are short and easy to type. If we're going to make this argument then why not call the unix tools `concatenate`, `difference`, `stream-editor`, etc. Those are way better names in terms of telling you what they do, but from a usability standpoint they stink to type out.
Libraries and programs also have a habit of gradually changing what exactly they're about and used for. Changing their name at that point doesn't usually make sense, so you'll still end up with long names that don't actually match exactly what it does. Imagine if we were typing out `tape-archive` to make tarballs, it's a historically accurate name but gives you no hint about how people actually use it today. The name remains only because `tar` is pretty generic and there's too much inertia to change it. Honestly I'd say `cat` is the same, It's pretty rare that I see someone actually use it to concatenate multiple files rather than dump a single file to stdout.
The author is missing the fact that stuff like `libsodium` is no differently named from all the other stuff he mentioned. If he used libsodium often then he may just as well have mentioned it as well-named due to it's relation to salt and would instead be complaining about some other library name that he doesn't know much about or doesn't use often. I _understand_ why he's annoyed, but my point is that it's simply nothing new and he's just noticing it now.
Short names are a figment of the age of teletypes when you had to repeatedly type things out. This hasn't been the case for at least 3 decades. Most good shell+terminal combinations will support autocomplete, even the verbose Powershell becomes fairly easy to use with shell history and autocomplete, which, incidentally, it does very well.
If you are repeatedly typing library names, something is wrong with your workflow.
Niklaus Wirth showed us a way out of the teletype world with the Oberon text/command interface, later aped clumsily by Plan 9, but we seem to be stuck firmly in the teletype world, mainly because of Un*x.
Without looking it up, is it sodium for "salt"? That's about as tethered to the actual use (salt + hash being a common crypto thing) as any of the names in the root comment
Used to be that Ruby's "rubygems" library had an alias "ubygems" so that when invoking ruby with the -r option (to require a library) you could say "ruby -rubygems". Sadly, they seem to have removed this alias library sometime around Ruby 2.4.
A friend created a library called library which was kind of a converse to that (you had to link it with -lrary). It was funny for 30 seconds and then just annoying.
cat is arguably from catenate, which is the smarter, shorter version of concatenate. By default, unadorned catenation is a joining (literally "making into a chain"), which is always together/with, so the con prefix is redundant. If you ever need a derivative of catenate that means splitting apart, you can coin discatenate, where the dis then plays an essential role.
Also, why is it that people are gregarious when they congregate, and not congregarious? Or why didn't they just gregate? There was such a Latin cognate verb without the con attached.
Because that's not how the prepositions worked in Latin. E.g. "Marcus ex casa exit" ("Marcus went out of the house") requires both the "ex" preposition and the "ex-" prefix in the verb. Heck, even today similar things can happen in English: "they gathered together", that sentence has two instances of "gather" in it.
It also seems wrong? libsodium explains the logic in its name right on its about page. It's a fork of NaCL (the chemical formula for sodium salt), which itself is a plain acronym for "networking and cryptography library." Google doesn't seem like a good example, either. Wasn't that meant to be an allusion to the very large number googolplex, as in Google exists to tame the unfathomably large amount of information on the web? The author may or may not like those names, but they have a logic just like grep and awk do.
sed is not "stream editor" as it says above, it's "stream ed", where ed was another prexisting program which was essential and everybody knew it. its name was from "editor" shortened.
the sed commands are the ed commands. so, it's almost not possible to say "i don't like the name", it rests on a rich tradition, it's the stream version of ed. (ed commands are very similar to vi commands at heart.) it's sad the unix crowd never grokked teco because teco was already a programmable stream editor from a tradition that was not particulary streamy. it predated ed by a decade and would have fit the unix world perfectly. maybe it was already too big? I'm sure they would have known about it. Emacs does come from the teco tradition.
grep got its name from what the "grep" command would look like typed within the ed editor.
awk should not be thought of as a tool, it's a programming language, and has every right to the name as ada or pascal or haskell does.
back in those days, filenames had to be short, long names were not allowed, no space, and also, people liked typing short commands. concatenate shortened is... well, cat is as good a name as any. back then the word console was popular for the name of the terminal connected directly to the computer (frequently already logged in), perhaps con was already in use then, it definitely had a meaning already on DEC operating system machines as inherited on Microsoft machines, CON: is still console, and Bell Labs was using DEC machines.
btw at some sites there is a "dog" command. it's like the "cat" command, but it starts at the end of the file and then shows any additions. so, if you want to see if anything is being added to a logfile, you can "dog" the file (which is completely broken when VMS Windows dorks show up and decide to make everything binary) now the verb "to dog" in English means "to follow closely", so it's a cute wordplay on cat and means what it does, similar to "less is more". in less, you can accomplish something like "dog" (dog with more context) with the "F" command. these individual pieces of wordplay don't form a coherent network in the end, but as new things are invented over time they are fun and help you remember new commands till you get used to them.
> ed commands are very similar to vi commands at heart
vi was build on top of ed.
Ed was the Unix line editor, which is why all the commands after a colon have the form of "start,endcommand", eg "1,$p" would list all the lines of a file on your tty/decwriter.
1,$s/findexp/replace/g would s ubstitute all examples ("g") of findexp on the lines 1 through EOF
And these all pretty much came from an era before glass display were (affordable) in computers. A terminal was roughly a keyboard and a printer attached together, or a typewriter cut in half. Paper. No cursors. No arrow keys. Mostly after punched cards and mostly before transistors. And that was only a few decades ago, there's people still alive that have used these machines.
Funny that they are still some of the most efficient and powerful interfaces.
I started out at school in 1977 on a PDP-11 with 16K of RAM, 3 ASR-33s connected by 20ma current loop. We also had a VT-52. All running at 110baud. No valves, all transistors and ICs. That system was already outdated.
Punched/mark sense cards were still around.
Two years later we had a PET, Apple-II, and a TRS-80.
Teletypes have been around since the 1940s.
Cut the false history crap when it's easily found online and elsewhere.
I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".
After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.
I've been using Linux for almost 20 years, including sed a lot of that time, I'm sure I've heard it before, I must have, but when parent wrote it I was like "aah, that makes sense".
I never forget what it does obviously, I use it at least weekly and most of the time daily. But if you asked me what "sed" stand for I'd probably not recall. I might have attempted to work in "extended" somewhere in a guess, because of ex the editor, but besides that :/
Don't forget that you need to know English for that to work. I'm pretty sure most Unix users don't speak English (most computer users definitely don't). I interact with people who know few words besides "hello" and "goodbye", and for them "sed" is a nonsense term, just a set of letters randomly thrown together. Same as e.g. Excel, a random token that means nothing.
sed is just an example, of course, the author's point doesn't hold much weight for many (most?) users globally.
lol no. There are literally a hundred plus Unix tools and commands. I couldn’t tell you what 90% of them mean. I sure as hell couldn’t have told you what sed stood for. And if you asked me tomorrow I also wouldn’t be able to tell you.
C programmers are great. I love C. I wish everything had a beautiful pure C API. But C programmers are strictly banned from naming things. Their naming privileges have been revoked, permanently.
It's `xaf`, because the modern world is way too complex for simple Germanic rules to solve it.
But GNU tar was never the issue. It's almost completely straight forward, the only problem it has is people confusing the tar file with the target directory. If you use some UNIX tar, you will understand why everybody hates it.
Someone once tried this on me during Friday drinks and I successfully conquered the challenge with "tar --help". The challenger tried in vain to claim that this was not valid, but everyone present agreed that an exit code of zero meant that it was a valid solution.
Some drunks in a gnu-shaped echo chamber concluded that the world is gnu-shaped. That's not much a joke, if there is one here. Such presently popular axioms as "unix means linux" or "the userland must be gnu" or "bash is installed" can be shown as poor foundations to reason from by using a unix system that violates all those assumptions. That the XCDD comic did not define what a unix system is is another concern; there are various definitions, some of which would exclude both linux and OpenBSD.
I seem to remember "tar xvf filename.tar" from the 1990s, I'll try that out. If I'm wrong, I'll be dead before I even notice anything. That's better than dying of cancer or Alzheimer's.
z requires it's compressed with gzip and is likely a GNU extension too (it was j for bzip2 iirc). It's also important to keep f the last because it is parametrized and a filename should follow.
So I'd always go with c (create) instead of x (extract), as the latter assumes an existing tar file (zx or xz even a gzipped tar file too; not sure if it's smart enough to autodetect compress-ed .Z files vs .gz either): with create, higher chances of survival in that xkcd.
is always a valid command, whether file.name exists or not. When the file doesn't exist, tar will exit with status '2', apparently, but that has no bearing on the validity of the command.
Compare these two logs:
$ tar xvzf read.me
tar (child): read.me: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
$ tar extract read.me
tar: invalid option -- 'e'
Try 'tar --help' or 'tar --usage' for more information.
Do you really not understand the difference between "you told me to do something, but I can't" and "you just spouted some meaningless gibberish"?
The GGP set the benchmark at "returns exit code 0" (for "--help"), and even with XKCD, the term in use is "valid command" which can be interpreted either way.
The rest of your slight is unneccessary, but that's your choice to be nasty.
Like I said, I was operating on a lot of zipped tars. Not sure what you are replying about.
The other commenter already mentioned that the xkcd just said "valid", not return 0 (which to be fair is what the original non xkcd required so I guess fair on the mixup)
That's part of the point, I believe. It's not about being always able to guess the function from first sight. It's also about the function and name serving as mnemonic to each other once you understand how it got named.
I think perhaps the articles argument gets less strong then?
It's claimed grep is "well named" because even though it's not obvious when you first read it, that it being a contraction for "global reg ex print" and hence memorable. I'm not sure the same argument can't be made for libsodium which assuming the reader is familiar with NaCl (the same as the assumption that the previous reader is familiar with regex) then it's an equally memorable name for your crypto library.
There's always a consideration about the context the name is intended and likely to be used in. The article mentions engineering naming and "ibeam", but engineering has it's own technical names an jargon as well. Most people wont know what "4130 tube" means, but people who build bicycle frames or roll cages will - and they're likely to use the less specific term "chromoly" if the don't need to distinguish between 4130 and 4145.
In my head "libsodium" is similar - if you don't know what it (and NaCl) mean, you 100% should keep out of that part of the codebase.
Names fall on a spectrum on this argument. Sodium is not really random because of the use of "salt" on crypto. It's like saying that libsodium is part of your crypto. awk is more random.
The argument goes stronger with projects where the creator seemed to just roll the dice with the name.
One additional complication with grep (and other CLI tools) is that the name itself is part of the day to day UX. It needs to be short, easy to say, and easy to type. With a library the API that is contained within serves the analogous role.
"libsodium" -> "salt" -> "salting is something tangentially related to cryptography" is significantly better as a mnemonic than "awk stands for the author's initials".
Same for grep - with, I guess, the proviso/assumption that you know what regular expression means, which might have been a fair assumption for the sort of people who had command line access to Unix systems in the 70s/80s, but may no longer be valid for developers under 30 who grew up with Windows and were perhaps trained in 6 or 26 week "bootcamps" that didn't have time to cover historical basics like that?
Regular expressions are more of a CS topic (regular languages), though common abbrevs of "re" and "regex" I've only seen in the wild pre and post my formal education in CS.
Yeah, I'd totally expect CS grads, old school Unix sysadmins, and Perl hackers to be fully familiar with Regex. Not so sure I'd expect that from bootcamp front end webdev "grads", self touch game devs, or maybe (I'm not sure?) engineers who have spent their careers in Microsoft dev environments.
> It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name.
Awk is short, easy to pronounce, and difficult to confuse with anything else. It's nearly as perfect as a name can be.
> 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.
You seem to have confused the concept of a "name" with that of a "description". The whole point of names is that they aren't descriptive.
"It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name."
I never really understood what was "wrong" with the NaCl library that it needed another version that does not have the string "nacl" somewhere in the name
I also remember Google named some heavily promoted non-cryptography project "NaCl" subsequent to the NaCl library's release making any searches for "NaCl" biased toward Google's software
I still use original NaCl, e.g., for CurveDNS, tinysshd, dq and dqcache, not libsodium
Well that's jargon in any industry. It makes no sense, you take a minute to learn it, and now it's part of your vocabulary.
At least these kinds of acronyms had utility once upon a time, when typing real estate was valuable and you input commands by hand for hours a day. Typing cat vs concat is hours of productivity save.
It's more that they weren't random. There was a convention, a lineage, or a rule behind them. Modern projects often skip that step entirely and jump straight to branding, even when the thing is just plumbing
The problem with current naming is it now using common names like coffee and it's hard to search for them or relate to them. At least the old Unix naming are kinda unique and sometimes means something. Unlike today.
Nitpick: Correct me if wrong but I think cat is catenate not concatenate
IMHO, the best names are the ones that are easiest to type. I have read several accounts of authors choosing names for this reason
I sometimes rename other peoples' executables (cf. libraries), not the ones in the traditional UNIX userland, but the ones with goofy names.^1 I will rename them to something I find easier to type and less annoying. I create symbolic links with the original names if I think they will be required^2
With own software, I give every program a number, the source file is named according to the number and the executable name is a short prefix followed by the number. All names are the same length. I have a text file that lists what each program does if I forget
I put a description in a comment at the top of each source file as a sort of header. Then I can do something like
head src/???.l
for a list of descriptions
1. Needless to say, Arthur Whitney's software does not get renamed. No need, he gets it
2. I will also rewrite the argument parsing and "usage:" output if it annoys me
The best way to determine what a program does is to read the source. This is one reason I prefer to compile programs from source instead of using "binary packages"
I also think the names that are chosen for so-called "tech" companies are routinely quite silly, but that's another discussion
i think you are misunderstanding the point. with awk, sed, grep they actually hold relevance to the tools whereas a file browser named "zephrus" holds no connection to the actual file browser.
> 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.
> > 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.
The author is just wrong. Chemistry is fairly jam-packed with various cutesy names either to amuse the authors or because they’re attempting to make an algorithm memorable to the field.
Off the top of my head:
- SHAKE and RATTLE: Bond constraint algorithms.
- CHARMm: An MD package but you’d never guess it from the name
- Amber: Another MD package that you’d never guess from the name.
- So so many acronyms from NMR: COSY, TOCSY, NOESY
The list goes on and on and permeates most of the subfields in one form or another.
If you want really cutesy names, though, look in molecular biology.
> - So so many acronyms from NMR: COSY, TOCSY, NOESY
My favourite: MAS, for magic angle spinning. Because every paper needs a bit of magic.
Scientists are the wrong population to pick if you want people who dislike silly names. They are everywhere because we don’t hate fun, and it does make things memorable. We’re also fond of naming things after people, which is as un-descriptive as it gets.
and at least that exposition makes more sense then the "fountain of youth brain juice" in the sequel, when the humans can literally reincarnate themselves without having to cross interstellar space to do it.
My physics teacher in high school used unobtanium in class and was the first I recall using it. This was way before Core or Avatar. After reading your wiki link, it fit perfectly with the definition of a frictionless, massless pulley use.
It's funny, because I'm one to use movie references in casual conversation like it's nothing, yet my use was definitely not in this case
America is named after some author writing about a "New World." America is sometimes erroneously used to refer to only one of the states instead of the whole continent.
Einstein doesn't tell me anything, unlike Müller (miller) and Schmied (Schmiede = Forge)
Off-topic, but it always amuses me that the sleepy town of Livermore, CA, known locally for its vineyards and an outlet mall, is immortalized in the Periodic Table, instead of the other greater places like New York or Chicago.
Chicago even had the world's first nuclear reactor, but no luck.
Ytterby is an otherwise pretty insignificant small town of 6k inhabitants in Sweden, but it has FOUR elements named after it: yttrium, terbium, ytterbium, and erbium.
Most of my examples are from computational chemistry, which is software, but (historically) written by chemists.
As one of those chemists (at least before my current work), I feel somewhat qualified to comment on my field and whether it always names things seriously or not.
But if you look around, fun terms are everywhere in chemistry or chemistry-adjacent fields. For example, PALM and STORM (from fluorescence microscopy) were almost certainly chosen because they were easy to remember.
> Also SHAKE and RATTLE describe the motion-simulation in the algorithm.
Not really. SHAKE and RATTLE are bond constraint algorithms to avoid simulating the fast degrees of freedom, typically in solvent.
In molecular dynamics, your time step is effectively set by the fastest degree of freedom (there’s a relationship with the Nyquist theorem here), so it pays to freeze out the vibrations of the O-H bonds in water when you’re simulating a larger system. SHAKE and RATTLE effectively freeze the bond and angle distances near equilibrium while allowing some relaxation.
The rest of the degrees of freedom are typically integrated with a larger time step using a method appropriate for the simulation ensemble (eg: one of the Verlet integrators, a Langevin integrator, etc).
> Acronyms are abbreviations for meaningful names.
Acronyms like XPS, EPR, NMR, etc are like that: dry, short, and meaningful.
But there are a lot that were chosen because they were entertaining to the authors or because they are easy to remember. Even in a technical field, marketing matters.
> Acronyms are abbreviations for meaningful names.
I think often words are added to allow for a memorable name, such as crispr
> When Mojica and Jansen struck up a correspondence, they began tossing around catchy names for the patterns, and on Nov. 21, 2001, they settled on CRISPR—an acronym for Clustered Regularly Interspaced Short Palindromic Repeats.
I think the author makes a hard distinction between consumer products and infrastructure/engineering products. The Shelby Cobra has a funny name, but its engine is the memorably named V8. The Hoover Dam is a dam, and the Golden Gate Bridge is a bridge.
We can argue about namespace pollution and overly long names, but I think there's a point there. When I look at other profession's jargon, I never have the impression they are catching Pokemon like programmers do.
Except for the ones with Latin and Greek names, but old mistakes die hard and they're not bragging about their intelligibility.
Yeah, V8 is the shape of the engine - 8 cylinders in two rows offset at an acute angle (i. e. V-shaped). Likewise a V6 has the same number of cylinders as an inline 6 but performs very differently. There's a handful of different engine shapes - I'm fond of the rotary engines used in early aircraft. Traditionally, the name of an engine was just the year, the manufacturer, and the displacement (like 1965 Ford 352). You often leave off the year and even the manufacturer if it's not required by context.
The Ford 351 is a bit special because there were two different engines made by Ford in the same time period with the same displacement, so they tacked on the city they were manufactured in (Windsor or Cleveland).
> 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.
In this example, you added "chopper", "patrol boat", and "handgun" to disambiguate them. There wouldn't have been enough context to do so otherwise, which IMHO is more aligned with the point the author was making.
If you were in the middle of a conversation about helicopters with people who knew lots of helicopter models, just saying "Cobra" would probably be fine. But in the software world, there are far too many obscure and new tools that are not at all clear without context. And the context just always happens to be all the dang things. A cutesy name could be any dang thing.
> It's a bad sign when all of the examples in an article don't even agree with the author's point.
I think you're just being selective because you disagree. A better example was:
> “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.”
If we want to cherry pick, your comment has:
> When you open your medicine cabinet
You used the term "medicine cabinet", a term that is not only descriptive, but not branded or jargon. It's standard and doesn't need something new. It's common usage and doesn't need to be disrupted by someone overly proud of a basic thing they made. You didn't call it Wapsooie, a "playful" take on WPSU (Wall-mounted pharmaceutical storage unit) or a MMC (Materia medica cabinet), or a whole host of other cutesy names or even acronyms that you might eventually get to if you were talking about medicine cabinets all day long, or designing or building them.
I mostly agree with the author. Software tools think they're so hilarious. I mean, the Virgil compiler is named "Aeneas" internally. Yet the cli command is "v3c"--Virgil III compiler.
My comment was mostly snarky, but I think the author is oblivious to their own biases and wrong. They even say:
> 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).
"diff" is a good name. There is no sane argument that "awk" conveys anything meaningful about what the tool does. "grep" is utterly opaque until you know what it's an acronym for. The name itself conveys absolutely nothing. "cat" is actively misleading because it is a word, but the tool has nothing to do with felines at all.
The author only likes those names because they're familiar with them, not because they're good names.
> You used the term "medicine cabinet", a term that is not only descriptive, but not branded or jargon. It's standard and doesn't need something new.
Sure. That's because I only have one medicine cabinet.
If I go on homedepot.com and search for medicine cabinets, the bold text is "Glacier Bay", "Zenith", "Kohler", etc.
What's frustrating about this article is that the author doesn't even realize why software packages have these funny names. Let's say I want to make a JavaScript package for parsing command-line arguments. Seems like "argparse" is a pretty clear name for that. Taken. Maybe "cliparse"? Taken. "args", "cli", "options", "argparser", "cli_argparser". Yup, all taken.
Packages need unique names so that package managers and imports can refer to them unambiguously. You can namespace them with the author's name but that just makes it confusing to talk about when two people say "args" but don't realize that one of them is talking about "@some_rando/args" and the other is talking about "@weird_startup/args".
So people just pick cute names. The name is an identifier, not a descriptor.
There is no real problem here, the author is just being cranky.
Military codenames are a bit different; they're deliberately random words, assigned so that no-one can guess the nature of the programme based on the name.
(Companies sometimes do this, too, for internal stuff.)
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)
I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names. A couple rules I’ve internalized are:
- if it’s hard to name, that’s a good sign that you haven’t clearly delineated use case or set of responsibilities for the thing
- best case for a name is that it’s weird and whimsical on first encounter. Then when somebody tells you the meaning/backstory for the name it reveals some deeper meaning/history that makes it really memorable and cements it in your mind
- the single best tech naming thing I’ve encountered (I didn’t come up with it) was the A/B testing team at Spotify naming themselves “ABBA”
God this article is 10000% better than the posted one. This is great:
> Names should not describe what you currently think the thing you’re naming is for. Imagine naming your newborn child "Doctor", or "SupportsMeInMyOldAge". Poor kid.
I totally agree with this, and will add that another benefit of whimsical names is discoverability. If your project is named plugin-update-checker and I want to find documentation on it, it's likely going to be buried in a bunch of other irrelevant search results about plugin update checkers in general. If it was called SocketToMe instead, I'm going to find much better search results.
I suppose it depends on your goals, but that scope restraint can be a good thing.
Do one thing, do it well, and while you're at it call yourself by the thing you do so you remember that's what you ought to be doing. A bit wordy for unix but you get the idea.
> 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.
In mobile telephony, one of the first things new hires are told is “don’t even try to work out what all the acronyms stand for; it won’t help”. You just have eat all the alphabet soup. Worse is that they nest themselves. You can have acronyms where every letter stands for another acronym. Writing a thousand words without using a single noun is easy. And of course all the short ones are overloaded. Is an AP an Application Processor or an Access Point? Depends on which subfield the person you’re talking to is from.
But they’re a necessary evil, since MSISDN is still less cumbersome than Mobile Station International Subscriber Directory Number.
The article's complaint (as I read it) is more about incidental load: names that force you to context-switch just to figure out what category of thing you're dealing with
> 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).
I agree. I've worked in places that discourage "cute" names and the result is often things like having to decide between using CoreMainHttp and MainHttpCore. Or worse, two things with exactly the same name, but two different APIs, with projects sometimes taking both as a dependency at the same time. Or even obsolete parts of the org chart encoded into dependency names, like "DataOrgUtils" when the "Data Org" stopped existing several reorgs ago, when our current VP was an intern and nobody else even worked here.
Without some central control of names though, even "cute" ones tend to converge on the same handful eventually: Phoenix (and other classical allusions like Plato's Cave, etc.), Keymaster/MCP (and other 80s childrens' movie references), Simpsons characters, Star {Trek,Wars} references. These are all attractors for the kind of people that tend to be in IT/SWE even if the actual namespace (all possible ASCII-expressable words) is much larger.
Exactly - the author thinks all these tools just materialized fully formed in their software ecosystem instead of surviving years of competition with other, less memorable tools. It takes many years of work, luck, and yes, marketing to get to the point where any of these tools are, and a memorable name can absolutely make the difference between support and oblivion.
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.
> but to claim we have "lost the plot" while holding up names like "awk" is contradictory at best
My argument is that even a name like awk is much more relevant to the people who used this software back then, of course it was not the best way to name it, but at least it held some meaning to it. Unlike modern software, awk and others were not written with the consideration of a wide user-base in mind. Regarding whether we "lost the plot" or not, I believe that we did, because as mentioned, in the 80s there was a current of people who named software conventionally, and up to the 2010s, the names still used to hold some rational even when word-played or combined with cutey names.
> It sounds more like this person just had a personal vendetta against cute sounding names, not against the names being uselessly non-descriptive.
Not at all, I find it quite fun, just unprofessional.
--
Sent by replying to an automated RSS email, via msmtp (light SMTP client, which is unlike firefox, not a consumer product and its name has to do with its function).
> My argument is that even a name like awk is much more relevant to the people who used this software back then, of course it was not the best way to name it, but at least it held some meaning to it. Unlike modern software, awk and others were not written with the consideration of a wide user-base in mind. Regarding whether we "lost the plot" or not, I believe that we did, because as mentioned, in the 80s there was a current of people who named software conventionally, and up to the 2010s, the names still used to hold some rational even when word-played or combined with cutey names.
I don't personally get it. I can see the argument for names that are descriptive, because a descriptive name might be useful. Meanwhile though, a name like awk is only useful if you already happen to know what it stands for, which to me seems a little silly. Relevant? Maybe... But to what end?
> Not at all, I find it quite fun, just unprofessional.
Why do you consider it "unprofessional"? This seems like a cultural thing. For example, in Japan, it seems like it is not unusual to see cute illustrations in otherwise professional contexts. I am not sure there is a standard for professionalism that is actually universal.
Disregarding that, okay, fine: let's say that naming software after irrelevant things is unprofessional. Why should we care?
Software developers have spent at least the past couple decades bucking trends. We went to work at white collar offices wearing khakis and t-shirts, with laptops decked out in stickers. Now I'm not saying this is all software developers, but it is certainly enough that it is a considerably recognizable part of the culture.
Professionalism, in my eyes, is descriptive, not prescriptive. If professional software engineers normally name things with cute nonsense names, then that is professional for our industry.
I can see the usefulness in descriptive names because they serve a purpose, but names that are merely somehow relevant but otherwise don't tell you anything useful seem just as useless as non-sense names, and justifying the distinction with "professionalism" feels odd.
> Sent by replying to an automated RSS email, via msmtp (light SMTP client, which is unlike firefox, not a consumer product and its name has to do with its function).
Note how this also neatly works as a strong argument against descriptive names. RSS? msmtp? We're now drowning in acronyms and initialisms. I don't particularly have anything against these names (I mean, I use msmtp and the name certainly doesn't bother me) but the utility of the name RSS is quite limited and the vast majority of people probably don't really know what it stands for (to my memory it is Really Simple Syndication, but it may as well be just about anything else, since that doesn't help me understand what it is truly useful for.)
But you do hit on an interesting point that probably helps explain to some degree what's going on here: even for small CLI utilities, more often than not programmers doing open source are actually bothering to work on the marketing and deployment of their software. When I was younger a lot of open source was still more decentralized, with many programmers just dropping tarballs periodically and Linux distros (and others) taking care of delivering the software to users in a usable form. Part of trying to deliver a holistic product is having a memorable name.
msmtp may not be developed as a product, but in practice, almost all software is like a product. Someone is a "consumer" of it. (Even if that person is also a producer of it.) People get "sold" on it. (Even if it's free.) How it's marketed definitely depends on the sensibilities of the developers and the target audience but I'd argue almost all software is "marketed" in some form even if it is non-commercial and not packaged like a product. (Even something like GNU's landing pages for things like Coreutils is arguably a very, very light bit of marketing)
The actual truth is software programs that have more care put into marketing are arguably more professional. The professionalism of having a "relevant" name is rather superficial in my eyes, but having concise "marketing" that "sells" your software well to its intended audience and provides good resources for users is professionalism that makes a difference. Likewise, plenty of things delivered more like products do have relevant names! For example, KeePass and SyncThing come to mind immediately.
So whether the next great email server suite is "SMTPMailSuite" or "Stalwart" is mostly immaterial, but I'm not surprised when marketing-concious developers choose memorable names. (Obviously in case of Stalwart, there's a company behind it, so having good marketing is absolutely in their best interest.)
Another downside of a descriptive name is that software evolves over time and a name that is too descriptive could stop being relevant eventually. Off the top of my head it's hard to think of a specific example, but you can see software that evolves this way all the time. (One example on the Linux desktop is how KWin went from being an X11 Window manager to a full-blown display server compositor during the Wayland transition; but that name obviously still works just fine.)
Fine, but then my critique moves over: the article should do a better job of conveying what the argument is and why it matters.
It opens with rms complaining about the names in the emacs ecosystem not being descriptive enough. OK. But the author argues (in these comments) that their argument isn't against names that aren't descriptive, it's just that the name ought to be relevant, and the reason why is because that is more professional.
Now I am paraphrasing so maybe I am not understanding the argument correctly, but I don't think that strengthens the case for this at all. If anything, it begs the question... why? (And I'm not sure rms would particularly buy this argument either, given that he beckons from hacker culture and seems perfectly happy to break social conventions. rms does not hit me as someone who is highly 'professional' in a traditional sense. This is not an indictment.)
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!
> 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".
Naming your library "data-testing-library" would be useful... until there's a second one at which point the specific name effectively becomes meaningless.
They also make things hard to talk about. When you mention testing library in an ordinary conversation without @ signs and dashes, people won't know whether you're talking about the concept of a testing library or a specific one.
Some people are passionate about being professional in the sense of doing things competently and expertly. Cuteness is inherently a mental distraction from what you really care about in the craft, which is why it appears tonally inappropriate. The desire to add some sort of cuteness is taken as an indication that the person apparently doesn’t derive enough joy from the workmanship itself. In other words, a lack of caring about and being fulfilled by the actual work, so that you need to add something “fun” on top.
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
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.
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"
Not at all. You don't name by category, you can name by function or approach. PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL). If your "LLM wrapper" does nothing distinctive worth naming, maybe don't publish it. But if it specifically handles streaming, call it something like "llm-stream-client." If it focuses on prompt templating, "prompt-template-engine." The name encodes the actual value proposition.
I actually stated this on the post, but let me reiterate, I think that naming things in somehow fun way is totally okay as long as it stays relevant to what the tool actually does (you can have this achieved by play wording suffixes (Mongo"DB", Open"SSL", Ma"git" are good examples, all are better than elephant, dog, and beaver).
> PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL).
Indeed. This helps me know that I'm using a database more modern than Ingres. I chose not to use Oracle or SQL Server because they might have predated Ingres.
Just one question: what's Ingres, and why do I care about it? Of course, I don't, which makes Postgres no more useful of a name than "fluffnutz" or "hooxup". That said, over time, I've come to like the name Postgres.
Sometimes names have great value at the beginning of the project. In this case it explains exactly what the project is and will be... That said, marketing decisions like naming a product often don't age well.
You don't need to know what Ingres is. "PostgreSQL" still tells you it's SQL-related, which is infinitely more than "fluffnutz" tells you. And once you learn it's a database, the name reinforces that knowledge forever. Good luck remembering what "fluffnutz" does in 6 months.
That's a really nice mnemonic. I wish I lived in an alternate universe where Postgres was called PostgreSQL so that it was easier to remember. Perhaps if we start using that, it will take over, like how everyone calls the Go project Golang.
When Google introduced the Go language, it was impossible to google for any content related to it. So community quickly pivoted to always saying golang ;)
(At least that's how I remember it as I was "why name a language like that when you know it won't be searchable")
> almost everyone refers to it as Postgres, because they do not actually value the descriptiveness of "PostgreSQL".
Also because the original name was, just, "Postgres". Stylized as POSTGRES.
PostgreSQL is an awful neologism (OK it's been around for a while now), and I honestly thought that they had decided to switch back to the original, and clearly superior, name. :) I recall it being under discussion several years back, and I am surprised it did not happen.
Sure, but how many LLM streaming clients are out there?
Namespacing, sure. But is "We use gh:someguy/openai/llm-streaming-client to talk to the backend" (x50 similarly cumbersome names in any architecture discussion) really better than "We use Pegasus as our LLM streaming client"?
Nobody says "gh:someguy/openai/llm-streaming-client" in conversation. You say "the streaming client" or "llm-stream" the same way you'd say "Pegasus." But when someone new joins or you're reading code, "llm-stream" is self-documenting. "Pegasus" requires looking it up every single time until you memorize an arbitrary mapping.
This sounds awful, now you'll be reading some documentation or comment about llm-stream where they didn't mention the full namespace, so you have no idea which of the 50 different llm-stream tools they're talking about, and on top of that you can't even search for it online.
I promise you, names are not self documenting. Not in any meaningful way.
This is one of those classic examples where things you've already learned are "obvious and intuitive" and new things are "opaque and indistinct".
We can go back and forth with specific examples all day: cat, ls, grep, etc are all famously inscrutable, power shell tried to name everything with a self-documenting name and the results are impossible to memorize. "llm-stream" tells me absolutely nothing without context and if it had context, pegasus would be equally understandable.
Maybe, and I would definitely prefer this to the random-generic-word practice. "illuminate" is some part of Laravel, but I can't remember what it is, just that "that's not even a noun; they just picked that word for $whatever_crappy_subsystem because it sounds nice" and being even more annoyed at the whole thing because of it.
> 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
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.
Oh, STEM naming… Especially mathematics. How can you tell that a "set" is different from a "group" different from a "manifold" different from a "category"? Then there is a lot of seemingly unrelated things called "space" (they are all actually a topological space, but when studying e. g. vector spaces one might not yet have been into that). "Field" is two absolutely unrelated things in physics and algebra, sometimes these domains even intersect! Linear programming, no real relation to computer programming at all, "programming" used to mean "optimization". Calling stuff after their discoverers might be non-descriptive, but giving a misleadingly descriptive name that also collides is way worse - yet people working with this manage just fine.
>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.
> don't even get me started on people naming their projects random Japanese words
But words help us learn. How many times do you notice a connection between some word from your childhood and an adult concept or place? And they're not random, people choose things because of many hidden reasons, but random is rarely the case.
Many of us love the story behind a word - as shown by many of the comments here reflecting on the cultural history behind our tool names.
> 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 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.
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.
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.
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.
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."
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.
When I told a co-worker about https://pypi.org/project/voluptuous/ he immediately searched for the name alone, got really wide-eyed and closed the tab, then told us not to do the same.
There was a markdown library called upskirt, the authors were bullied into renaming it. They called it Misaka, because that's an anime character that uses shorts under her skirt.
Maybe a geekbench from yesteryear. Back in the mists of time it was apocryphally known as "eight megs and continually swapping". But I guess that's a couple of orders of magnitude out nowadays.
> 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.
Editor MACroS still has a logic. It isn't just random.
More to the point, what does a John Deere S7 600 do, or a 310 G-Tier, or a Z515E ZTrak? Emacs is an editor. That part is descriptive: an editor edits. The product name is not expected to describe what the product is. The general product category is what does that.
> The product name is not expected to describe what the product is.
There are some exceptions, but the agriculture machinery industry has actually gotten pretty good at making the names useful, with reasonable consistency across brands. S7 600: 600 tells that it is a class 6 combine, which is a value farmers understand as it pertains to the combine's capacity. For tractors, the John Deere 8R 230 sees 8 indicate a large row-crop frame, and 230 indicates a 230 HP engine. A New Holland T7.180 is, you guessed it, a medium row-crop frame with a 180 HP engine.
It may look like nothing to outsiders, but there is a lot of useful information encoded in there once you know what to look for.
Useful if you already know the basics of what it is. My point is that "S7 600" by itself doesn't tell you anything if you don't have some knowledge of the product already. The knowledge that it's a combine is separate. Similarly, "emacs" tells you nothing if you don't know it, but the generic term "editor" is descriptive.
Software doesn't generally encode product attributes into the name the way 230 means 230 horsepower and such, but that's because software doesn't really have things like that to put in the name in the first place. Most software doesn't have specific variants like that, and software that does is almost always differentiated on feature set rather than numbers.
Software often puts the version in the name. Which is the same as the S7 designation in the case of said combine. S7 is just a restyled S7x0 series combine, which was the successor to the S6x0 series.
It's not a perfect system. Before the S6x0 was the 9x70STS series, after the 9x60STS series, and the 9x50STS series. You can find a version number in there, albeit not a perfectly sequential one. Although that's nothing new. Windows 3.1 turned 3.11, 95, 98. iOS 17 turned 26. You get the picture.
Technically it is "combine". Originally it was known as a "combined harvester-thresher", which is maybe what you're thinking of, but that was soon shortened to "combine" and it has stuck ever since.
"Combine harvester" showed up in some places later where context was needed to figure out what "combine" means, but it was seemingly only for context. "Combined harvester-thresher harvester" is pointlessly redundant.
I'm conflicted because you're not entirely wrong (that it's not just the software industry), but the name is because the combine combines steps that used to be separate.
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.
I used GIMP before I ever used Photoshop. My experience was the opposite. I think that means the UIs are different, but there is no one that is objectively better, it's just a matter of what your expectations are, which are set by whatever you learned first.
As for CMYK support: why do designers even need to use this? Sure, not every RGB is the same, and it took some while before we even got sRGB as some standard, but the same goes for CMYK: every printer has its own profile. I had the displeasure of trying to get the CMYK profile of a "professional" printing company that only accepted files in CMYK, and they didn't even know which profile their printers used. Ideally you would send a RGB file including the display profile your screen uses, and then the printing facility converts that to whatever CMYK they need.
Of course there are also special colors or effects outside of RGB/CMYK that you might want to use when printing something, that's something else.
GIMP has god horrid UX, there's no way it could have eaten Adobes anything.
There's lineage of FOSS apps that stick by the "we're not X, we're different from X." mantra.
The discomfort, frustration and unintuitiveness you're feeling from using our app? It's just you!
No, that's not bad design and bad UX! its simply because we are different! We aren't X (Photoshop), we just do things differently here!".
We've implemented a number of items from the issue posts once consensus was reached, and we hope more people will participate and help improve GIMP further.
I agree GIMP is a bad name, but is it really a 'solid' competitor to Photoshop? My impression has been that it was never close to being competitive on features. I've only used either of them very briefly so I may be wildly wrong though.
IIRC, it was too expensive to make Gimp support non-RGB color spaces needed for professional image editing.
I use it semi-regularly and it does a great job for me, and most of UX is clear and obvious (high DPI support is lacking). But I haven't used Photoshop since the 90s (or Aldus PhotoStyler before it was acquired by Adobe ;)).
I think it could have been -- which is to say, I think a better name earlier on could have well been what could have gotten more contributors etc etc. Network effects and such.
> which could have perhaps eaten Adobe's lunch MANY years ago.
That "perhaps" is doing a whole lot of work in that sentence. GIMP has never, even now, been a serious competitor to Adobe's products for professionals. To suggest that if they simply had a better name they would be the top dog is laughable.
Be careful. The language police have already got rid of "master". They were eyeing up gimp for a takeover or rename but I don't think it got very far. Perhaps all their energy was spent on removing the slavery from git.
It's about professionalism. It's a tradeoff. I see both sides of getting rid of e.g. "master;" but GIMP is so well beyond. Even if you make the argument that it's not offensive you're still stuck with a name that absolutely connotes "this thing is not going to be good at things."
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.
“Have you seen the new show? It's on Tubu. It's literally on Heebee. It's on Poodee with ads. It's literally on Dippy. You can probably find it on Weeno. Dude it's on Gumpy. It's a Pheebo original. It's on Poob. You can watch it on Poob. You can go to Poob and watch it. Log onto Poob right now. Go to Poob. Dive into Poob. You can Poob it. It's on Poob. Poob has it for you. Poob has it for you.”
Indeed, however I would point out that the approach of naming things after elements or processes ex. Sodium results in not-so-unique names in certain contexts. Ex. if you're working in a lab that deals with the element or process, then confusion can result with colleagues.
> 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"...
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.
To be honest, `awk` that the author references to as a good name, is not. It's just the initials of authors, which does not convey anything about what the tool does. It's yet another cognitive tax.
And I would go further, the extremely shortened names in Linux and other places is problematic too, given that most terminals now allow name completion on tab.
Tab completion being a thing does not take away from short, memorable names being easier to use. You'd likely end up typing more on average, due to multiple programs sharing the first few letters of their name
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.
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.
>> 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.
"names conveyed purpose or origin.": no they don't. If I use the authors example of the two people talking: as if saying "BASIC" instead of "Cobra" explained the meaning anything better to a person who never used BASIC.
I've been programming for 15 years+ and never used basic due to my age and I never know, until today, that BASIC stands for "Beginner’s All-purpose Symbolic Instruction Code".
Why? Because I don't need to know and it doesn't make the usage of BASIC anything different.
I really could go on about this. Names are only useful for distinct identification. They need to be distinct within their domain. Otherwise they're just an index into a list.
Sonic hedgehog is a terrible example this case. Researchers literally had to tell parents their children had mutations in the "sonic hedgehog gene." The scientific community recognized this was a problem and it's a widely-known controversy. It's cited as an example of bad naming in medical ethics discussions.
Boaty McBoatface? officials overrode the vote to name it after David Attenborough. The actual research submarine got the joke name. Again, this proves my point.
Fat Gary was an internal chip designation that never needed to be public-facing. Perfectly fine.
"Names are only for distinct identification" if efficiency was not at a question. Why use worse identifiers when better ones cost the same?
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 "<>".
End of the day you know what it means or you don't. I agree it's helpful when a name is descriptive, but there's no helping the fact that you're going to have to learn the names of things that aren't obvious. Purely utilitarian names would constantly collide.
I also think they overestimate how distinct terminology is in other fields. Even their example of the I-beam is also known as an H beam or an RSJ depending on who you're talking to. I don't find it hard to imagine a mechanic referring to one of their specialty tools by the name of its manufacturer, either.
Regardless, the battle was lost before it started. There has never been good consistent descriptive naming as standard in computing; there was no plot to lose.
Just love of whimsy is part of it, not denying it. But other parts of it are that a generation or two on, a lot of the straightforward names are taken.
(Also, I wouldn't say `awk` or even `grep` are good examples (as the OP admits) -- they were definitely chosen for whimsky, with, if not actually backronyms, still acronyms deisgned for whimsy).
And another part of it is that so many people now have dreams of commercializing their product, so you need a "brand" name. (I guarantee the namers of the tools had no designs on commecializing grep or awk). (I have little sympathy for this one, but it's the world).
I do agree with OP it is a problem for accessibility. Newcomers who haven't already memorized the mangagerie have a lot to figure out; some people's brains work differently than others and it's easier or harder for some people to remember these arbitrary names naturally; I'd guess it can be especially hard for non-native English speakers, but maybe it's all Greek (ha!) to them anyway, so.
When i have tried to name things plain though, I often have trouble -- we want something clear, but also relatively short (especially if it's going to be in namespace or other identifier names and be typed a lot!) -- and not already taken in popular consciousness or the package managers we'll need etc, and often I have trouble finding such!
the problem with technical software names is that they are either too long, too pointless, do not die when underlying tool goes through re-incarnation(looking at you angular) or worse, too important to be wasted on a lesser quality project (looking at you react-router).
in my company, we have a tool whose technical name was four word long, and has just as much cognitive load as any technical name.
one of my biggest contribution to that project was to Name it.i gave it a simple name, with zero relation to tech or any software
and suddenly our PMs, Managers, Users can pronounce it and can actually type it correctly and of course recall it's name flawlessly.
so, at least from my experience, having a small, easy to pronounce name is more important than having technical name.
Moreover having a name with all of the qualities is definitely desirable, but there are many projects in world and not that great names. and many Great names (looking at you, Vue.js) are either already taken or beyond my naming skills
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.
There's another comment that points out that a g-le search will pick up few false positives (disclaimer, have not tried myself). So the initial 'WTF' gives way to 'well, ok, I see what you are trying to do'.
This is a norm to the point of being a rule for Elm packages. The names are things like elm-csv, elm-json-decode-pipeline, elm-iso8601-date-strings. There's a strong preference in the community to name a package for exactly what it does, and differentiate on the author namespace if needed e.g. you may choose among coreygirard/elm-nonempty-list, mgold/elm-nonempty-list, and v-nys/elm-nonempty-list depending on which meets your needs best
I remember working on a ruby project and running into some problem with our env setup tool and just hitting "could not find nokogiri" (or an error to that effect) over and over and getting a little mad that I had to read this cutesypoo not-at-all descriptive name over and over while failing to get a danged website to run.
---
To be sure, there are in-the-know parts of all the package names I just listed: what does JSON stand for? What does CSV stand for. What is the ISO and what is 8601? I guess the idea there is the descriptiveness ends at the edge of the language; the package name is too short a field to explain Javascript Object Notation, Comma Separated Values, or the ~~International Standards Organization~~ ok actually it's from "isos" meaning "same" date format.
I’m glad you cited Ruby, as it’s definitely the exact opposite of what you said about elm. Every damn gem has an idiotic cutesy name. I think it’s one reason why every mature Rails project I’ve seen in the corporate world has direct dependencies on five or six different http client wrappers. New developers would look in the Gemfile, find no “http” anything, then google “ruby gem http client” and, since that happens to be a diverse category, eventually developers will find and add all such libraries.
I’m hoping that with AI, maybe this will be less common, because an AI agent should easily see that you have, say, Faraday installed already, and not bring in the noob magnet that is httparty.
> 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.
Yes and no. The Navy has or had a lot of code in JOVIAL, Jules's Own Version of the International Algorithmic Language. SNOBOL goes a long way back.
> 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.
Well if they work for a drug company they will say “Let’s call this phlogistotheremone but sell it under the name Zyphyrax so that doctors and patients will refer to the same medication by different names.”
>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.
Odd? Modern? I started working professionally in 2005 and everything had silly names. The DNS server was named athena instead of c302r5s1 or whatever building/room/rack/position name. I once rebooted a server that had an uptime of 12 years, so it had been running since 1993... it indeed had a silly name. Everything had silly names, usually types of things had a theme.
>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.
How about piranha? aqua regia? Up/Down/Strange/Charm quarks? Gluons? Like a third of the elements named after people or places.
Curium, Einsteinium, Fermium, Mendelevium, Nobelium, Lawrencium, Rutherfordium, Seaborgium, Bohrium, Meitnerium, Roentgenium, Copernicium, Flerovium, Oganesson -- I guess none of these people were named Steve, but you get the point
These tendencies are OLD and EVERYWHERE. IUPAC names are just a convenient way to serialize data.
One issue with package naming is competition. One of the great things about OSS or software in general is people can take inspiration from other projects that do the same thing. Personally I've ran into deciding which casting library to use
AJV and runtypes use the naming convention that the article suggestions. It's named is derived from how it's used. Zod on the other hand seems to come from left field.
Personally, I built a simple caster called "ShallowCaster" before choosing to move to a library as things got move complex but I think a problem is that as competition increases the "generic" naming becomes more difficult to find.
I suppose an option is to include the author name for each package such as "json casting from google" or "@google/json-casting" this way all packages can use the descriptive naming while not conflicting
Great post and I think this extends to machine learning names, although not that severe. Maybe it all started with Adam. When I say “I used Adam for optimization” this means I used a random opaque thing for optimization. If I say “I used an ADAptive Moment estimation based optimizer” it becomes more transparent. Using human names or random nouns has been a trend. Lora, Sora, Dora, Bert, Bart, Robert, Roberta, Dall-e, Dino, Sam… With varying capitalization for each letter. Even the Transformer. What does it transform exactly? But it gets worse. Here is a list of architectures that may replace Transformers [0]: Linformer, Longformer, Reformer, Performer, Griffin, BigBird, Mamba, Jamba... What’s going on?
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
We had this debate at my company and the end result was a ban on “random” service names.
So we ended up with “auth service” instead of something like “Galactus”. The problem of course is that “auth service” isn’t searchable in our monorepo and it was a nightmare to find or discuss any info or references to the service itself. Now imagine if docker was called “container manager”. Good luck googling that and disentangling it from all the search results.
The value of a name doesn’t come from it being self-explanatory but rather from it being a pseudo-unique identifier. The small cognitive tax of remembering it serves as a shared bookmark between people that you can refer to when discussing or speaking to others about it - whether we’re talking about docker, Linux, or another person.
It's especially fun once the service is superseded. Guess which one of these services handles MAC address allocation and storage: macaddr_db or atom-util?
Worse is the Git UI, where random English words that seem to have a clear meaning in the context of source control don't do at all what you think they do, or five different things, or are really just a bunch of other commands wrapped together for less typing (like "pull").
I would rather have fantasy names than wrong names.
> 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.
> Same thing applies to other fields like chemical engineering [...]. 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.
I realize this isn't chemistry, but aren't there like 15 elements that are named after people (Curium, Einsteinium, etc) another handful named after places (Americium, Tennessine, etc).
Also, a bunch are named after Norse and Greek gods like Thorium, Titanium, Plutonium.
The article also goes to talk about the Hoover Dam, but it's not like the government is immune to this either. We just had Operation Warp Speed which doesn't tell you anything about what that program did
The author is vastly overestimating the general legibility and familiarity of things they happen to know well and are used to.
Boring names are also very generic, by definition, and thus often harder to remember. Especially when there are 10 other similar tools. Is it sql-validator, sql-schema-validator, schema-validate, db-validator, or god knows what else?
Edit: I am in favor of better “sub titles” / descriptive slugs / and so on. As well as names that are a hybrid of creative and descriptive. Sqlalchemy is a good example.
Why isn’t there a command line utility called “whatisthis” with a standard protocol that allows tools to give a brief description of what they are?
It could be extended to package managers as well. E.g “pip whatisthis foo_baz”.
The real trick is getting just enough meaning into the name to be helpful, while keeping it distinct. SQLAlchemy is a great example.
I called by zsh bookmark tool `tutu`, my idea was to make it sound like what it does.
- It helps you go TO places
- The main command is `tu` because it is short, a homophone of "to", and wasn't already taken
- Additional commands `tutu` (which does a `pushd` instead of `cd`) and `untu` (which is just a wrapper around `popd`) are short, memorable, and pronouncable.
All of those naming decisions were made with ergonomics in mind.
Was I successful? I like it. A few other people are using it and seem to like it, too.
To the extent that I was, I think it's because the name is meaningful enough while remaining distinct.
This might not be exactly what you mean by a CLI app called "whatisthis", but I have been using cheat.sh and the pattern below for a few years. It works really well!
I'm not sure arguing in favor of alphabet soup naming is any better. At least we ended up with semantic versioning, because originally it had also been just an expression of marketing and creativity. I don't understand even slightly why he blames Google in the article. He also forgot to propose what he believes Google should have been named. Search Engine? AWCSS? And the fact that he'd be fine with Viper and Cobra if they had backronyms points to the ridiculousness of the whole article. I'm genuinely most fascinated by how he accomplished writing that much text without the nonsense of his position dawning on him.
The examples given for real world things The Golden Gate Bridge and The Hoover Dam, are instances of things. Things that the class of which they belong is old enough that Dam and Bridge are not new words.
If you are making new things you need a new name. Software is inherently new because computers have been in wide use for only a few decades. Instances of software rarely even get names, just numbers, with project names or nicknames attached. I'd be willing to bet both The Golden Gate Bridge and the Hoover dam had project names or nicknames.
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.
I believe the phrase I'm looking for is hallelujah!
The naming culture is beyond salvation. It crossed the line when things went from 'We invented this word to name our thing.' to 'We fused the concept of breakfast muffins in cat pictures meme to the previous application of the open source tool to name our abstract thing more accurately. That's why it's called
7Mermaids.'
I remember when Yahoo had to spend a fortune on commercials asking "Do you Yahoo?!" It seems that old business lesson was completely forgotten.
> 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!)
You are correct, my apologies. It was at work where we have NannyWare of various sorts, so it might have been that. Working fine from home; thanks for confirming.
We have an internal name and our product name. Internal names start as something that describes the project/repo/tool. Then within 18 months the name no longer makes sense so we rename it to some random name - state names, lake names, presidents, mountains, etc. It's just a placeholder.
The public facing product name is a compromise of marketing, trademark, and what gets approved by the CEO. Even the company name might change in startup world. No joke: the startup next door had to change their name because it was too masculine, and they realized more than half their projected market was women.
This is the way, you name things random words devoid of all connection to software because you don't want to confuse people later when the scope grows or changes.
Well so in the beginning we only supported email notifications which is why it's called EmailServ but over time
it grew into a robust and pretty general queueing service so now it handles all our background task processing. Sending emails is actually handled by EmailWorker but EmailServ still supports its original API which now uses EmailWorker behind the scenes if you prefer 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
Would it be better if it was this:
> We’re using ConfigurationManager for configuration management, which feeds into CLI for the CLI, and then WebSocketHandler handles our WebSocket connections, PermissionManager manages permissions, all through JobQueue for our job queue
I think the author makes the opposite point of intended)
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.
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.
Yes, but it's fairly light-touch moderation. Newly registered first packages go through some automatic checks, and if they pass all those checks they are put on a 3-day waiting period for community to give feedback or raise objections to the package, and then at the end of the 3-day period, if nobody blocks it, the package is registered.
One of the automatic checks is a name similarity check, and if the name is too similar to an existing name, then the package is blocked from being auto-merged. At that point, someone will look at it, and there'll be a discussion on whether or not the name is okay. A lot of the time, the response is just "this is a false positive" and the package is greenlit. Other times, there's a discussion on whether or not the name is acceptable, and some alternative suggestions are given.
_______________
There was a little episode recently where someone tried to register a package with the same name as an existing package, but with two letters tacked onto the end of the name. Their package was just a fork of an existing package, but with a minor patch applied becuase they were frustrated that maintainers of the existing package weren't responding to pull requests.
The system automatically flagged the name, and the person was initially upset that they couldn't just register their fork, but within a couple hours we tracked down a maintainer to fix the existing package, and then we added this person as a maintainer to the original package so that they could review and accept pull requests to the package themselves. I think this ended up being a better solution for everyone involved.
I believe one of the things that prompted stallman to give that talk was the inclusion of the lsp client "eglot" in emacs. Eglot i think is short for emacs polyglot.
The most idiomatic name, lsp-mode, was taken by another package. Stallman wanted to find another name but no one seemed to care as much as he did. I think one name he suggested in its place at one point was "code-parse" or something like that.
This essay is not consistent. They ramble between company names Google ( which is a great name ) and tools like AWK which is not descriptive at all but a good name.
But I do share his pain with onboarding when I joined Humungous Entertainment the tools or systems were called Sputm, Phlegm, Mucus, SPIT. There might have been a Bile. :-)
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.
A lot of the issue has to do with marketing. Some people name their tool for the pizazz it might generate and gain them fame or it's an actual company motivation. Instead of a hammer is a hammer and a heavy hammer should be named "heavy_hammer".
EDIT: I just noticed that the marketing angle is mentioned in the article.
I agree, some names that come to mind are Celery and Windows. But there are always silly names. I like Plan 9, an OS named after an Ed Wood B movie. Its sibling, Inferno is full of puns and references to Dante Alighieri's Divine Comedy. Its corporate dullards who insist that neutral boring is appealing to most and I again agree but its not a hard rule for me.
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.
Why does nobody in SF say "I am going via the San Francisco-Oakland Bay Bridge", but shortens it to just the "Bay Bridge"? This is the reason some bridges get a nice name (like Golden Gate), and some are strictly utilitarian (like SF-Oakland Bay).
And I am sure there are other "Bay Bridges" in the world too.
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).
Why does it have to be all or nothing? How about a clever name or two for marketing that stands out and doesn't get lost in a sentence "I'm not asking you to search, I'm asking you to use the search command" but not obnoxiously over done where everything is named after some Norse god or some other silliness.
Thete is no way to give descriptive names unless it is a single centralized system. Names need to be consistent, this is the main requirement for a good set of names. When the whole set is consistent, individual names can be nearly arbitrary, it won't matter much.
There was never a plot to follow; if there isn't a better name for an editor than "vi" (because "ed" is already taken) then maybe they should try getting rid of verbs too to give it more "refreshed" branding.
How do conference-room names fare in this view? My current company names them after football teams or local landmarks. But I heard about someone who used to work somewhere that named theirs after WWII battles, which was awkward for the Japanese guy they interviewed in one of them.
Descriptive naming absolutely helps at first contact, especially when you’re scanning a dependency list or onboarding someone new. No argument there. But in practice, names stop carrying meaning pretty quickly anyway
There are many different tools that attempt to solve the same problem, with varying levels of competency.
They can't all use the same name. If you want to build a better alternative to an existing solution, you need to choose a different name, this leads to names being arbitrary.
I am highly sympathetic to this sentiment, but I think it's hard to name things in software because a) it's easy for the obvious names to get overloaded and b) many of the things we are dealing with are basically abstract relationships with arbitrary properties.
This drives me crazy because I use dmenu to launch things, and every time I want to launch a subsonic client I'm like "blueberry? Wayshin... Weish... Fei... FEISHIN!"
Just call it "subsonicfeishin" or something at least!
> 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.
I almost completely disagree with this post. The only thing I can consider that you should probably avoid embarrassing names.
A descriptive name is terrible if you're slightly off. Or if the library gets repurposed. Or if the project doesn't turn out how you expected but it's still helpful. With everything going on, a nonsense name forces people to learn about it instead of having them guess at it from a three word description that might be misleading.
The author probably never had a project where something got named the oscilloscope-controller but there's no oscilloscope in sight, but we used to have one and then we tweaked a few things and now it runs something else and but the name was everywhere.
And all of these are abstract concepts. Getting data from point A to point B. FIFO? It's an acronym. Pipe? Doesn't really suggest it can buffer data. Buffer? Queue? Both sound like they might slow down data. Precise technical names would be good, but then the chances the purpose changes goes up!
I can't call my new formula translation language FORTRAN because it's been taken, as have many other names. So now to avoid collisions, it's named after my cat.
I strongly agree with this. And what bothers me more than obscure or meaningless names like Viper are silly and embarrassing names like Hunchentoot. Names like that sometimes cause people to dismiss good software. It’s like using Comic Sans in a serious research paper.
One area of the sciences does partly use names like this, and that is biology. Biologists do sometimes name a species after a famous person, as in the louse Strigiphilus garylarsoni:
I agree. One recent example is in the Zig community a popular tool for benchmarking is "poop" [1] (Performance Optimizer Observation Platform). It could have easily been "pop" (Performance Observation Platform) and been cute enough without being intentionally cringe. Every time I see Zig now I think about "poop".
I'm happy to see this post, it's something that bugs me every time I have to learn a new tool with a name that's neither A. unique to the project AND B. doesn't describe the project.
For example Zola and Hugo, static site generators - great, unique words that has no other meaning to me but the generator. The only other Hugo I know is a character in Bob's Burgers. But choosing random dictionary words like Avocado or Spice or whatever makes it completely transparent against my existing knowledge and now I have the mental lookup issue the author describes.
The other day a HN user was commenting "NAT, aka IP masquerading... (proceeds to keep re-using the term)". IME no one in the industry says "IP masquerading" unless your entire org and vendors are on Linux. Just call it NAT, we know what you mean. This a Linuxism and should be avoided!
Let's hit up Britannica.com on the word:
> a party at which people wear masks and often costumes
> a way of appearing or behaving that is not true or real
> to pretend to be someone or something else
I guess? I guess we are "pretending to be the peer IP when actually we are the LAN IP". But to me it's just nonsense. It's capital T Translating one IP to another for the sake of routing, drop the weird social implications.
> Your HTTP client, cli utility helper, whatever library is not a consumer product.
I'm not sure how the author came to this conclusion.
At any rate, programmers aren't any worse about this than mathematicians. Just replace [fictional name] with some foreign word or philosophical term that's justified with the most insane mental gymnastics you've ever heard of. Given some historical native speaker of Latin, do you think they're going to know what a matrix is for? No, because the word means "uterus". There is no connection to "tabular shorthand of linear transformations."
I think it's clear the author is writing this to vent frustration, but I think they've misidentified the actual problem:
> http-request-validator is infinitely superior to “zephyr” when someone is scanning dependencies at 2 AM debugging a production incident.
My jaw hit the floor reading this. The idea there are people out there debugging codebases without knowing something as foundational as the dependencies is beyond absurd to me. That's insane and horrifying, overshadowing pretty much the entire blog post. Does anyone else live like this? How do you tolerate these conditions? Why would you tolerate these conditions?
- Almost everything on blogs and HN are opinions, so don't take things things too seriously
- Fun and humour are subjective, and a substantial part derives from novelty and subvertin expectations. It's hard to make something fun for an audience that has already seen such dozens of times.
- The audience('s background and expectations) is diverse and varies with time. So what's considered "fun" is audience specific and often cyclical.
> 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.
My favorite: there's a protein called "sonic hedgehog" that's essential to animal embryonic development. (All of the "hedgehog" family proteins would cause fruit flies to take on a spiky appearance when mutated, hence the name.) When chemists synthesized a drug that suppresses SHH protein's action, they named it "robotnikinin".
The Drosophila people had the best naming schemes. I really wish we kept up the whimsy of gene names. One I enjoy is RING; "really interesting new gene". I have always said if I find a gene of interest, I'd call it RUNG.
I find the remark that we give things names more as a word play than purpose.... kind of amusing? Like, of course people will find a way to play with the tools they have. And in programming, that is often words. Because what else would it be?
By far the worst aspect of the nerd ecosystem is the odd belief that pops up every so often that names should matter. In every ecosystem, there is usually some odd idea that it is only in their world that people abuse this.
Just skim through that list of things that are unexpectedly named after people. Sure, you can get upset about Shell's sort not having any relation to shells. Or Bloom's filter not having a phase where the data "blooms" into use. But you would have the same issue with French drains. Or how gaslighting has nothing to do with lighting things on fire using gas and the affect that will have.
Honestly, I think this would be a fun list to just keep going. Akin to the old Chuck Norris joke generators.
> 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? Have you specced a microprocessor lately? Seen what pharmaceuticals are called? How polymer compound materials get named?
The "Raptor Lake" codename in microprocessors is internal, the product ships with systematic designation. Engineers spec chips by model numbers that encode generation, tier, and performance class.
In Pharmaceuticals, Doctors prescribe "sildenafil," not "Viagra." The generic name describes chemical structure. Brand names are marketing for consumers, not professional nomenclature.
Mythology in chemistry/astronomy has centuries of legacy and connects to human cultural history. Calling an element "Titanium" after Titans carries weight. Calling a SQL replicator "Marmot" connects to... what, exactly? A weekend at the zoo?
"Raptor Lake" isn't an internal codename, it's very much external as it's what Intel actively referred to that generation as. How's a non-geek shopping for a PC going to know if it's better or worse than "Lunar Lake" or "Alder Lake"? Maybe they just think their machine is shipping with some game where your giant dinosaur bird thing has to stop off for a quick drink to regain energy.
But in any case, this isn't the real travesty with these names. It's that they're reusing existing common words. The article hates on "google" when actually it's a fantastic name - if you googled it when it was introduced, all the results were about what you wanted. By comparison, Alphabet is an awful name, because if you search for Alphabet only a tiny subset of the results are going to be useful to you.
Naming schemes in consumer marketing serve a function. They are easily identifiable, unique, and memorable. All of these properties serve to identify the thing by associating a unique name with a unique set of services/function/effects on use.
Medical and chemical terminology is built on the history of latinate terms and compounds whose simples follow the same pattern. Latinate terms, I might add, which reference mythical, fantastical, or unusual things. Consider the planet Mercury, for example. The only difference? The centuries of time it took for scientific evolution to turn these unique names into a taxonomical language with its own logic.
There is no such taxonomy for computer science. But in the course of the evolution of such a taxonomy, it will be built out of the mess of names like the ones we like to use for our programs and tools like Rust, Ocaml (notice combination of interesting and technical), git, npm, bun, ada, scipy, etc etc.
Depends on the location, I guess. I've had doctors prescribe trade names, which I don't understand if there are alternatives with the same dosage, route of administration and similar inactive ingredients. Not even talking about the "do not substitute" prescriptions which are also based on dubious information most of the time.
As for "sildenafil" - I don't think generic names are usually meaningful. Usually the suffix relates to the category of the drug, but the first letters seem as random as the letters in trade names. I could imagine a world where the generic name is viagrafil and the trade name is Silden.
Generic drug names don’t describe chemical structure, they allude to purpose but that’s all. ‘-afil’ is used to apply to a particular class of drugs, although when it was discovered, ‘sildenafil’ was the only example of that class, so it didn’t mean anything already.
This is like having the first tool of a particular type come along and call itself ‘Mosaic’ and then someone makes another tool of the same kind and calls it ‘Mozilla’.
Brand name pharmaceuticals are sort of a different thing. Brand names must comply with the naming guidelines of the FDA, European Medicines Agency, and HealthCanda simultaneously. In practice, this makes it tricky to use actual words. So my companies adopt an 'empty vessel' naming approach. The empty vessels are nonsense words that (1) invoke an emotion (wegovy is a good example), (2) can be trademarked, and (3) it can survive brand pressure.
> Your HTTP client, cli utility helper, whatever library is not a consumer product.
> (...) Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste
Devs who build FOSS utilities owe you, or the industry, absolutely nothing. As someone who lists Noam Chomsky under "Some works I recommend engaging with", you sure seem to think capitalists are entitled to people's free work, to the point where you start making demands.
I could not disagree more. If you say "Ben told Mary that he would work with Scott on Jeff's house on Tuesday, but that Amy preferred Wednesday", that sentence carries a lot of meaning for the speaker and listener because those "names" have meaning to both parties. Nobody would tolerate the descriptive alternative: "General Contracting Company Owner told General Contracting Company Secretary that he would work with General Contracting Company Hired Hand #4 on Customer #22's house on Tuesday but Customer #22 Spouse preferred Wednesday".
The names have always been quirky, but the new names mostly seem to be chosen for some branding / marketing reason (which I don't like). You can basically put "[any noun] javascript library" into google and find something. The space is so saturated that the names have become more and more disconnected from what they describe. Someone should go create labubu.js so people are less inclined to do so themselves. You can benchmark it with matcha (not to be confused with matcha.css).
For example, naming some application modules strictly after what they do is super tedious, and uses words that are already reserved, therefore creating ambiguous nomenclature. Maybe I have various sort of permissions in my system but naming that particular permission system some greek god name creates a clear and shared meaning across the team (both business and technical), and mind you that that's what communication is all about - a shared meaning. Nothing else.
P.S. (I'm deliberately not going into discussion about bad things with that approach)
"...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... "
I would not mind the command names whose etymology was complex or inspired, if the README files would do a better job of giving context and function. Even though I have a wide set of wheelhouses in computer systems, I frequently encounter README files that still leaves me saying "Huh?". I shouldn't have to google three levels down before I get a clue.
This is a pretty tangential to the article but Debian is just about the worst there is here. An application will be given a friendly name in an attempt to make it more user friendly. (eg: gedit is called "Text Editor") But, there is often no way whatsoever to map the friendly name back to the actual package name. Want to uninstall gedit? Well if you don't already know what it's called, good luck.
I’m 100% with OP on this. So many posts on the front page have names like “Hamburger — a tool for doing a thing.” These names are neither memorable nor distinctive, good luck trying to look them up later.
This reads like an extensive, and frankly exhausting, rationalisation of a personal preference. Personal preferences are fine, I have my own. But please stop thinking they apply universally.
Laravel works better than Rails-but-PHP. Ruby on Rails beats Opinionated-One-Person-Stack-Using-Ruby and I'm fine with the name Ruby as well.
I shall name my next product larmn in honour of OP.
Wait till you work in a corporate environment, where Project Fuzzy Mustard triggered a violation of the ElastoFish metric in the Yellow Hills subsystem, leading to a Code Mild Lavender with a side of Pink Sprinkles.
I agree for internal names but disagree for public software/external names.
I disagree for public/open-source software, because:
So many kinds of software actually have good names. Yes they use mythical names but with the similar function or relatedness.
Meanwhile, I agree for internal names, because:
So many (legacy) code I worked with had terrible naming. This goes beyond only the names themselves but also their capitalization or consistency. I kid you not, in a $FAANG company I saw "SpidermanActivity" and "BatmanActivity" on a system that is used by Tier-1 services' on-calls.
> (Although this thing was not a Tier-1 service, it was not also completely Tier-2 either, as it was actively supporting operations of Tier-1 services, depending on the incident, a downtime could cause significant problems...)
Imagine you are trying to make sense of a large system, which has maybe tens of dependencies and as much of dependents, you are also trying to remember which API was Spiderman and how it related to the business at all...
More on the naming conventions, the horrible case of acronyms (which spans outside of software engineering) and PMs creating polls/surveys for "fun names for our new shiny thing that does X but we don't wanna call it that".
Going even lower-levels, engineers themselves are not careful. I had way too many CDK stacks named with not only varying dash vs underscore differences, but also with subtle "case-sensitivity" differences.
Each year, I am solving issues of Java devs' issues. Some of being "but it works on my machine" type of problems. And significant percentage of that is most developers use a Mac & macOS. Hence the filesystem is case-insensitive by default. But the deployment target & CI being a Linux, filesystem is case-sensitive. As you can see here, The camel-case combined with inattentiveness can simply cause many hours of waste.
> It's a plague.
Yes, there is an AI slop, but there is also human sloppiness too. I am quite happy with LLMs/GenAI that it is able to catch and capture these and less prone to make such sloppiness in the first place. (As it being a "predictive-text engine", next word suggestion is a clone of existing copy of historically occurring words)
At the same time, amount of "hallucinations" for various acronyms are staggering. Obviously I cannot expect otherwise. Even as a human, if I am missing the context, I would be either confused or plug-in something I already know...
"“We’re using confman for configuration management, which feeds into climan for the CLI, and then wsconn handles our WebSocket connections, permgr manages permissions, all through jqueue for our job queue”"
This is better? Is this Highlander, there can only be one of each thing? What about variations of those tools... cman2? confman? cfigmgr? Naming projects, and hence tools, is often just as much about namespacing as meaning. There _will_ be more than one of most non-trivial tools/projects, and not every configuration manager can be called "confman" (if that's even really a "good" name").
And part of it _is_ connecting utility to an "appelation": calling "your MIT-licensed file parser with 45 GitHub stars" just "parser" practically gaurantees you'll never get that 50th star, because there are already a bunch of "parser" projects and there is no reason for someone to ever find yours.
"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."
No they don't, because you're _not_ doing that processing every time. Just like "grep" makes perfect sense _now_ because you've used it forever, once you're working on a project then something like "cobra" immediately maps to "the cli library". It might take a secon the first couple times, but humans are good at this internalizing kind of abstraction, and programmers are damn amazing at it.
The unix tools example is really terrible. "I used grep to examine the confs in etc and then cat to combine them before processing with sed and awk and tarballed the output to be curl'ed to the webdav server." Those are only intuitive because you know them already. "sed" for "stream editor"? Come on, it's not called that because it's a good name. Why not strmed, or even streameditor?. Simple, actually intuitive. It's because 'sed' was the bare minimum to be a short as possible while being unique and just memorable enough. Awk is an even better counter-example to the article's claim: it's just names, makes no sense! Has literally _nothing_ to do with what it does.
"the Golden Gate Bridge tells you it spans the Golden Gate strait."
Umm, no it doesn't tell you that. Does the Brooklyn Bridge span the Brooklyn strait? George Washinton Bridge? Bridges are not exclusively named by that which they span, and software is not exclusively named after exactly what it does.
> InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?
> Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.
There is actually a good reason not mentioned, not to name tools by their purpose:
- the purpose will change
Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else.
Or your "login-page-config-service" tool may eventually do more than just logins.
Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particular thing which may or may not be correct anymore.
Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.
Project names should be unique enough to allow them becoming their Id,
- It allows to find the project.
- It allows the project to change, extend it's scope or narrow it.
Having an Id is really important, making that Id related to the project's original intention is nice, but secondary. (as long as it doesn't change enough that it becomes misleading).
"purpose will change" argument actually proves the opposite point. When a tool's scope expands beyond its name, the descriptive name tells you something went wrong. But even if so, if you have to rename "login-page-config-service" to "auth-config-service" it is not really a big deal, renaming will be much cheaper if you're renaming to descriptive names. Most importantly though, I wouldn't optimize to avoid renaming (happens once, maybe twice in a project's lifetime) by making discovery hard (happens every single time someone encounters the tool).
> renaming will be much cheaper if you're renaming to descriptive names
Idk, renaming things that shipped is a PITA.
Say you wanted to rename `fish` to `a-decent-shell`.
- Packages in all distros would need to be renamed.
- Configuration for all systems using/having fish would need to change.
- Scripts would need to change, from the shebang to the contents if necessary.
- Users would need to understand that they now need to search documentation using the new name.
- Documentation would need to be migrated to new domains, sed-replaced, and reviewed.
All this migration would require some synchronized, multi-step process across multiple distros and deployments.
> Say you wanted to rename `fish` to `a-decent-shell`
You just made my argument. Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
Every cost you listed [distro packages, configs, scripts, docs, domain] exists whether you rename to something descriptive OR another random word. The migration pain is identical. "Fish" → "decent-shell" costs the same as "fish" → "zephyr." My argument was that this renaming won't be necessary if you started by picking up the proper name at the first place, and it's very unlikely to have the need to rename it. We shouldn't be optimizing to avoid renaming. That's trading a rare maintenance event for permanent cognitive overhead.
> Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
No, it's just because the goddamn string Id appears in way too many places and you can't sed-replace the entire world at once. It doesn't matter if the string was cute, fancy, or you found it to be a good name.
A good reason to use arbitrary code names before assigning a more helpful name upon release of something deemed to now be generally usable, beyond developers with caveats.
I like this approach. Use a cute, fun, memorable name internally for stuff getting off the ground. Once it becomes user facing, the internal name becomes a fun note on Wikipedia and the world sees the actual calculated name.
This just feels like an old man yelling at clouds, trying to convince himself that the grass in greener in the other field.
> 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 happens every day. In every scientific field there is a technical name and then the name everyone remembers. Nobody will understand if I speak about ENSG00000164690, but if I say it's the Sonic HedgeHog gene then it starts to make sense, because funny names are memorable.
> awk (Aho, Weinberger, Kernighan; the creators’ initials)
I'd like to see anyone try to defend how using the creator's initials in a tool name describe its function. Unless you researched the tool's history, there is no way to know that.
Yet another "why the tools I use are the best and the tools you use suck", with a weird focus on naming instead of function.
What are some examples of names that Windows does better than macOS and vice versa?
I've always though iOS naming was pretty logical - Calculator, Notes, Messages, Mail, Health, Clock, Calendar, Photos, Contacts, Maps, Settings. They're all named as if they're the reference implementation and everything else is 3rd party.
Under Windows we have Notepad, Paint, Terminal / Command Prompt. Word and Excel are likely household names so it's tough to ask a random person who's never heard of them to describe their purpose. But they did have "Clipchamp" which was a pretty dumb program IMO.
Windows is pretty bad, but I have to give the dark pattern award to macOS for being overbloated with services. Especially if you're an average Joe; wouldn't you assume that AppleTV plays your video files, and Apple Music focuses on playing your MP3s? How are you supposed to know that Quicktime is the less intrusive option? It's hidden in a glut of inscrutable, outdated apps like Automator, 3D Chess and the graphing calculator everyone opens by accident. At least Windows knows to hide the cruft apps from the Start menu.
It's gotten to the point with macOS that I don't think my parents could use it. They use Windows just fine without knowing the difference between Terminal and Command Prompt, but macOS would be a mnemonic shoggoth too far.
LMAO ok dude, don't like it? fork it and change the name. The author has a DEEP misunderstanding of the science of human language, not surprised he's a Chomskyite.
Rule of thumb, disregard every post that uses the phrase "context switching"
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.
> I couldn't for the life of me tell you what dd stands for.
Data(set) Definition. But that name does not make any sense whatsoever by itself in this context, neither for the tool (it hardly "defines" anything), nor for UNIX in general (there are no "datasets" in UNIX).
Instead, it's specifically a reference to the DD statement in the JCL, the job control language, of many of IBM's mainframe operating systems of yore (let's not get into the specifics of which ones, because that's a whole other can of complexity).
And even then the relation between the DD statement and the dd command in UNIX is rather tenuous. To simplify a lot, DD in JCL does something akin to "opening a file", or rather "describing to the system a file that will later be opened". The UNIX tool dd, on the other hand, was designed to be useful for exchanging files/datasets with mainframes. Of course, that's not at all what it is used for today, and possibly that was true even back then.
This also explains dd's weird syntax, which consists of specifying "key=value" or "key=flag1,flag2,..." parameters. That is entirely alien to UNIX, but is how the DD and other JCL (again, of the right kind) statements work.
I just remember it as "Da Disk", early 2000's nu metal lyrics-style, because it does mad things to da disk, yo.
I guess the most relevant backcronym expansion is still "Disk Destroyer"
"Data Deleter" was how I always remembered it!
I had remembered it was "convert and copy", but cc was already taken by the c compiler so they shifted it down a letter. That might have been apocryphal.
Same here. But I also seem to remember claims that this isn't true…
I had it learned as "data duplicator" or something like that... seems also bogus.
Having come from the DOS world (or it could have been Norton utilities), I always thought it was more like DiskDupe (duplicate disks).
Funny how we never confirm our hypothesis that "checks out".
"disk dump" is another common (but wrong) guess.
I always read it as “[disk|data] destroyer”, because that’s what it’ll do if you’re not careful.
You know, this is true. And I've read any number of "you should never use dd, use this instead" articles over the years. But man, do I love me some dd.
dd is the software equivalent of removing the riving knife from a table saw.
Then again, I get very paranoid when I write software that has to delete arbitrary files recursively. One bad string gets in there and it's a very bad day.
One explanation that left a deep impression on me is[1]:
[1]: https://unix.stackexchange.com/a/6835/192313Reminds me of IBM => HAL, just the other direction
APL -> BQN where the author remembered the alphabet wrong : https://chat.stackexchange.com/transcript/message/54753804#5...
i always think of it as Data Destroyer
Ha, for the last 30 years I have been convinced it was Disk Direct.
I thought it was dirty deeds.
I feel obliged to point out that C++ is C postincremented, that is to say it has the same value as C, but after you read it C gets incremented. The metaphor is flawless.
By the same token, the sharp sign in C♯ is two plusses put together, and represents going a (half) step above C. Also, a minor second is one of the most dissonant intervals in western music, which is also a brilliant metaphor for how well C♯ meshes with C.
Even GNU is a recursive acronym, Emacs a convoluted one... What's Perl, Python, Java... all about? Remember how JavaScript was named? Don't mention Go (go-lang) or Pascal... Git, Mercurial, CVS anyone?
I believe this makes much ado about nothing.
"Concurrent Versions/Versioning System" is a pretty reasonable one, though.
Then Gimp is also a great name, right? GNU-is-not-Unix Image Manipulation Program: immediatelly obvious what it does as soon as you learn what the acronym stands for.
Or Gtk even: Gnu-is-not-Unix Image Manipulation Program ToolKit (later changed to refer to Gnome instead of Gimp I believe).
and gdk was, delightfully enough, the gnu's not unix image manipulation program toolkit drawing kit
Java is easy - named after the coffee beans of the coffee they used to drink...
CVS (noticed already mentioned by a sibling comment) is just an abbreviation.
Python - well Monty Python
Java was originally called Oak but its creator because he could see an oak from his office, but marketing people at Sun thought Java would be more catchy. Yes it's named after coffee beans, but it has no relation whatsoever to the language or the way it was created, it's just a marketing name.
I can totally see how that was an obvious decision in the 90s, the coffee shop craze was just taking hold in America, and it was such an exciting and fashionable thing to do to sip espressos and lattes.
Imagine a parallel world in which Java is called Oak and it's actually nice from inception, not just like nice after decades.
compared to C, java was quite nice
Yes, I am simply highlighting that programmers have not used descriptive names consistently... well, ever (reinforcing the point the GP made).
The entire premise of the OP is simply wrong.
Pascal is probably the most sensible name, as far as traditional naming schemes go. Names after Blaise Pascal, mathematician and one of the two inventors of the mechanical calculator. Pretty fair association and tribute.
Git as a name is our daily reminder that pre-mainstream programmers were rebellious against the mainstream (to put it as generously as I could) before corporate interests took over. but i encourwge you to look up that story yourself.
>Git
The stupid content tracker.
Still one of my favourite names.
The 2000s Plan9 community asserts "Gnu is Not Useful" as the correct expansion.
It would be funny if I did not run GNU/Linux as a daily driver since 1998: Plan9 did look interesting too, and compared to GNU/Hurd, it was certainly in a better shape.
(Even Solaris, *BSDs already started including GNU tools, compilers...)
Perl stands for “practical extraction and report language”
Also "pathlogically eclectic rubbish lister".
The article even refers to AWK as being the initials of the authors. And posits this as "reasonable"?
Naming is hard, not least because "a million" new projects are spawned every day. And if you're going down a path of "rule the world" (even in a niche like infrastructure) you start by getting a .com domain, so choices are limited.
Plus the name has to be unique enough to Google.
> I couldn't for the life of me tell you what dd stands for.
Traditionally, according to folklore? "Delete disk" or "destroy data". (Because it was commonly used to write raw disk blocks.)
I always assumed part of the "data destroyer" folklore was from people flipping if/of by accident and destroying their data :)
I thought the more common mistake with dd was picking the wrong disk to write to (especially when using /dev/sdc type naming instead of /dev/disk/by-id/whatever naming). Flipping source/dest and overwriting data is a problem I associate with the tar command.
Another, similar name it is sometimes jokingly referred to under is “destroyer of disks”.
https://web.archive.org/web/20081206105906/http://www.noah.o...
I always thought it was "disk dump"
https://en.wikipedia.org/wiki/Back_Orifice_2000 was pretty clear about what it did.
https://en.wikipedia.org/wiki/BitchX less so.
In the same vein, my recollection is reading that the X windowing system is called X because it's the letter after "W", which was the original choice (because it's what the word "window" starts with), but it was already taken, so they went with X.
It looks like X was deliberately chosen to denote succession of W, not clashing with it:
-- https://dl.acm.org/doi/pdf/10.1145/22949.24053I think I sort of meant the same thing, but my wording might have been unclear. Essentially, there already was a W, and they were making something new, so they picked X.
Wow. Wayland really should have considered “Y” apparently!
> what dd stands for
https://groups.google.com/d/msg/alt.folklore.computers/HAWoZ...
The only thing that's different between the era when Bison as named and now is the proliferation. There is vastly more shit in open source with the cute names. Back then, one person could keep all the cute names for everything related to C and Unix in their head.
>The only thing that's different between the era when Bison as named and now is the proliferation. There is vastly more shit in open source with the cute names.
I personally think that's a pretty good idea for coming up with better names instead of cute names now.
Naming is a big part of programming, you'd expect software to have good descriptive names.
How do you discriminate between 2 different things that ostensibly have similar features, but do it in different ways without getting very large names? What if you modify software or just part of it to make it something distinctively new, should it keep the name or add to it? What if I revert that non-trivial feature and add a different non-trivial one. Now what is it?
I would hope the author realizes the core counterpoint when re-reading "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" - because the real names, are the roles the tools play. The implementation name is incidental and amorphous, since you can make wild changes to software, rendering the name without much utility beyond a project label. Project labels are necessarily opaque, for the same good reasons software is. The ideals are more important than the details. They are a conflux of interests and plans, not a market label. If market labels were fixed to functionality, the world would be worse off for obvious reasons of practicality and marketability. Ironically, Stallman is completely comfortable with PostgreSQL which is semantic context adjacent, charitably. It describes a small element of the project (a synthetic SQL syntax), not the project itself.
I think this runs into the intersection of the "code is art" and "code is a tool" crowds. I like to name my API methods with a little whimsy too...
I remember writing a function to convert a string from snake case to camel case and calling it `humpify`. And another that would take a string and locate the constant with that name called `constantinople`.
But then, this is ruby and it's known for its unusual naming. Plus both also had sensible/boring aliases and they were for internal use only.
> you'd expect software to have good descriptive names
Like Microsoft Word?
"There are only two hard things in Computer Science: cache invalidation and naming things."
And off by one errors.
"And off by one errors"
eh, in 2025 SEO ( Whatever the jargon is for LLM) is as important or perhaps more important so that you can search and find documentation and issues etc
I agree we never had it in the first place, and that it ultimately doesn't add up to much. It seems like just a familiarity problem.
If I'm diagnosing something at 2AM, I don't care whether my database queries were written with Zapatos or PG-ORM, even if the latter is clearer. As long as you use the tools, you know what they do.
There are two hard problems in computer science: caching things, naming things and off-by-one errors.
This, plus it's less obtuse than drug naming, and about on par with any other random product on the market.
Which is not to claim the general market is full of good names - clearly it is not. But I don't think it's below par at any point in its existence.
> UNIX was UNICS which was a pun on MULTICS.
I doubt it is official, but I was told the name Unix was picked as it was "Multics with bits taken off".
> I couldn't for the life of me tell you what dd stands for.
I always assumed “data dump” or something like.
So maybe the takeaway isn't "we lost the plot" vs "we never had it," but that there's always been a tension
GNU stands for "GNU's Not Unix".
Yacc stands for "Yet Another C Compiler".
Nano was originally TIP which stood for "TIP Isn't Pico" but was later changed to Nano so as not to conflict with another Unix utility called tip [0]. Presumably nano was chosen as the metric prefix next larger than pico.
Personally, I'd prefer choosing a random string of 3-8 letters for command line tools. At least that would be better than naming programs using generic names (Keep, Bamboo, Chef, Salt) which leads to all sorts of name collisions.
From the article:
> This would be career suicide in virtually any other technical field.
The mascot for an $8.8T dollar (supply side) software industry, larger than Google, Microsoft and Apple combined, is a cartoon penguin [1].
"never had it in the first place" is absolutely correct.
[0] https://en.wikipedia.org/wiki/GNU_nano
[1] https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-...
Yacc is Yet Another Compiler Compiler, not Yet Another C Compiler. It's useful for writing compilers, not for compiling C.
Especially since, IIRC, it actually predates C.
Yep, my mistake! And it makes a lot more sense.
> "never had it in the first place" is absolutely correct.
To be clear: I didn't mean to imply this is a bad thing.
GNU's Not Unix, Pine Is Not Elm, TIP Isn't Pico all share one important characteristic — their audience is expected to know what Unix, Elm, Pico are, and saying "X is not Y" implies "X is specifically, deliberately an alternative to Y, in the same style as Y".
If you know what GNU and YACC are, you probably don't need to be told twice that "Bison" is GNU's YACC implementation — the pun makes it instantly memorable.
One of my personal favourites is Ubuntu's version naming scheme. The "alliterative animal" form is highly memorable, and gives you two different words to latch on to, either of which is enough to uniquely identify a version. The fact they're alphabetical also makes it easy to check which version is newer (Letter collisions happen on a 13-year cycle, which makes it highly unlikely to be a source of confusion).
> their audience is expected to know what Unix, Elm, Pico are
Of course, the context for these references are all kind of anchored in the 90s. Someone first discovering Bison in the year of our lord 2025 is unlikely to have the foggiest clue what YACC was...
Pretty sure dd is disk destroyer
> Yacc is called Bison
And when they named ‘Yet Another Compiler Compiler’ something tells me they weren’t being deadly serious.
dd = (D)oes what it says it (D)oes
> 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.
Yeah this definitely falls into the category of "I use them so they feel natural", there's nothing amazing about those names.
The underlying problem is that you now run into so many named things (utilities, libraries, programs, etc.) in a day and they all have to differentiate themselves somehow. You can't name every crypto library `libcrypto` for obvious reasons.
Fine. Name it sodium-crypto.a or sodium.crypto.a or whatever. The author's complaint does hold water.
You can, but then the names get needlessly long and one of the things we generally like (especially for command-line programs) is names that are short and easy to type. If we're going to make this argument then why not call the unix tools `concatenate`, `difference`, `stream-editor`, etc. Those are way better names in terms of telling you what they do, but from a usability standpoint they stink to type out.
Libraries and programs also have a habit of gradually changing what exactly they're about and used for. Changing their name at that point doesn't usually make sense, so you'll still end up with long names that don't actually match exactly what it does. Imagine if we were typing out `tape-archive` to make tarballs, it's a historically accurate name but gives you no hint about how people actually use it today. The name remains only because `tar` is pretty generic and there's too much inertia to change it. Honestly I'd say `cat` is the same, It's pretty rare that I see someone actually use it to concatenate multiple files rather than dump a single file to stdout.
The author is missing the fact that stuff like `libsodium` is no differently named from all the other stuff he mentioned. If he used libsodium often then he may just as well have mentioned it as well-named due to it's relation to salt and would instead be complaining about some other library name that he doesn't know much about or doesn't use often. I _understand_ why he's annoyed, but my point is that it's simply nothing new and he's just noticing it now.
Short names are a figment of the age of teletypes when you had to repeatedly type things out. This hasn't been the case for at least 3 decades. Most good shell+terminal combinations will support autocomplete, even the verbose Powershell becomes fairly easy to use with shell history and autocomplete, which, incidentally, it does very well.
If you are repeatedly typing library names, something is wrong with your workflow.
Niklaus Wirth showed us a way out of the teletype world with the Oberon text/command interface, later aped clumsily by Plan 9, but we seem to be stuck firmly in the teletype world, mainly because of Un*x.
libeay
`eay` is just the initials of the original author, so basically the same thing as `awk`.
> The author's complaint does hold water.
Ironically, much like sodium itself, a substance of which the author seemingly possesses too much of.
Without looking it up, is it sodium for "salt"? That's about as tethered to the actual use (salt + hash being a common crypto thing) as any of the names in the root comment
https://en.wikipedia.org/wiki/Libiberty was always my favorite ridiculous name. It was named so you can link it with -liberty.
Used to be that Ruby's "rubygems" library had an alias "ubygems" so that when invoking ruby with the -r option (to require a library) you could say "ruby -rubygems". Sadly, they seem to have removed this alias library sometime around Ruby 2.4.
It was removed because rubygems was made to be required by default so it was now useless.
The stdlib still contains `un.rb` though: https://github.com/ruby/ruby/blob/d428d086c23219090d68eb2d02...
Wow, I did not about un.rb. Looks cool though.
A friend created a library called library which was kind of a converse to that (you had to link it with -lrary). It was funny for 30 seconds and then just annoying.
There is also https://github.com/gebi/libowfat
cat is arguably from catenate, which is the smarter, shorter version of concatenate. By default, unadorned catenation is a joining (literally "making into a chain"), which is always together/with, so the con prefix is redundant. If you ever need a derivative of catenate that means splitting apart, you can coin discatenate, where the dis then plays an essential role.
Also, why is it that people are gregarious when they congregate, and not congregarious? Or why didn't they just gregate? There was such a Latin cognate verb without the con attached.
> Or why didn't they just gregate?
Because that's not how the prepositions worked in Latin. E.g. "Marcus ex casa exit" ("Marcus went out of the house") requires both the "ex" preposition and the "ex-" prefix in the verb. Heck, even today similar things can happen in English: "they gathered together", that sentence has two instances of "gather" in it.
It also seems wrong? libsodium explains the logic in its name right on its about page. It's a fork of NaCL (the chemical formula for sodium salt), which itself is a plain acronym for "networking and cryptography library." Google doesn't seem like a good example, either. Wasn't that meant to be an allusion to the very large number googolplex, as in Google exists to tame the unfathomably large amount of information on the web? The author may or may not like those names, but they have a logic just like grep and awk do.
Even more directly, in fact.
"Google" is from "Googol", the latter being 10^100. Apparently, "Google" the corporate name is an accidental misspelling of the number.
The number (googol) has no mathematical special properties and the name was invented by a 9-year old in the 1920s.
Googolplex is 10 to the googolth power, so 10^(10^100).
And Googleplex is the MV campus of Google.
it should have been called chlorine for "Cl" is the cryptography library in "NaCL"
I’m not sure I like awk, sed, or cat, I think these are just names we’re used to, not good really. diff seems ok.
grep almost has an onomatopoeic nature to it… like, it sounds like you are grabbing or ripping the patterns out of the file, right?
>I’m not sure I like awk, sed, or cat
sed is not "stream editor" as it says above, it's "stream ed", where ed was another prexisting program which was essential and everybody knew it. its name was from "editor" shortened.
the sed commands are the ed commands. so, it's almost not possible to say "i don't like the name", it rests on a rich tradition, it's the stream version of ed. (ed commands are very similar to vi commands at heart.) it's sad the unix crowd never grokked teco because teco was already a programmable stream editor from a tradition that was not particulary streamy. it predated ed by a decade and would have fit the unix world perfectly. maybe it was already too big? I'm sure they would have known about it. Emacs does come from the teco tradition.
grep got its name from what the "grep" command would look like typed within the ed editor.
awk should not be thought of as a tool, it's a programming language, and has every right to the name as ada or pascal or haskell does.
back in those days, filenames had to be short, long names were not allowed, no space, and also, people liked typing short commands. concatenate shortened is... well, cat is as good a name as any. back then the word console was popular for the name of the terminal connected directly to the computer (frequently already logged in), perhaps con was already in use then, it definitely had a meaning already on DEC operating system machines as inherited on Microsoft machines, CON: is still console, and Bell Labs was using DEC machines.
btw at some sites there is a "dog" command. it's like the "cat" command, but it starts at the end of the file and then shows any additions. so, if you want to see if anything is being added to a logfile, you can "dog" the file (which is completely broken when VMS Windows dorks show up and decide to make everything binary) now the verb "to dog" in English means "to follow closely", so it's a cute wordplay on cat and means what it does, similar to "less is more". in less, you can accomplish something like "dog" (dog with more context) with the "F" command. these individual pieces of wordplay don't form a coherent network in the end, but as new things are invented over time they are fun and help you remember new commands till you get used to them.
> ed commands are very similar to vi commands at heart
vi was build on top of ed.
Ed was the Unix line editor, which is why all the commands after a colon have the form of "start,endcommand", eg "1,$p" would list all the lines of a file on your tty/decwriter.
1,$s/findexp/replace/g would s ubstitute all examples ("g") of findexp on the lines 1 through EOF
And these all pretty much came from an era before glass display were (affordable) in computers. A terminal was roughly a keyboard and a printer attached together, or a typewriter cut in half. Paper. No cursors. No arrow keys. Mostly after punched cards and mostly before transistors. And that was only a few decades ago, there's people still alive that have used these machines.
Funny that they are still some of the most efficient and powerful interfaces.
FFS, I'm not that old. I'm 61.
I started out at school in 1977 on a PDP-11 with 16K of RAM, 3 ASR-33s connected by 20ma current loop. We also had a VT-52. All running at 110baud. No valves, all transistors and ICs. That system was already outdated.
Punched/mark sense cards were still around.
Two years later we had a PET, Apple-II, and a TRS-80.
Teletypes have been around since the 1940s.
Cut the false history crap when it's easily found online and elsewhere.
> sed is not "stream editor" as it says above, it's "stream ed"
Well, according to the man page, it is indeed "stream editor":
https://man.cat-v.org/unix_8th/1/sed
I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".
After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.
They're good names because they're short and easily recognizable
There are only so many short names to go around.
Well yea. These guys got dibs some 35f years ago or so. Maybe more. First come first served.
However once you learn that sed means stream editor, you won't ever forget it. libsodium is forgettable.
> However once you learn that sed means stream editor, you won't ever forget it.
I feel like this is approximately the third time I'm learning this.
I've been using Linux for almost 20 years, including sed a lot of that time, I'm sure I've heard it before, I must have, but when parent wrote it I was like "aah, that makes sense".
Thirty years for me and several more since I learned what sed does and what it's called and never forgot.
I never forget what it does obviously, I use it at least weekly and most of the time daily. But if you asked me what "sed" stand for I'd probably not recall. I might have attempted to work in "extended" somewhere in a guess, because of ex the editor, but besides that :/
Don't forget that you need to know English for that to work. I'm pretty sure most Unix users don't speak English (most computer users definitely don't). I interact with people who know few words besides "hello" and "goodbye", and for them "sed" is a nonsense term, just a set of letters randomly thrown together. Same as e.g. Excel, a random token that means nothing.
sed is just an example, of course, the author's point doesn't hold much weight for many (most?) users globally.
lol no. There are literally a hundred plus Unix tools and commands. I couldn’t tell you what 90% of them mean. I sure as hell couldn’t have told you what sed stood for. And if you asked me tomorrow I also wouldn’t be able to tell you.
C programmers are great. I love C. I wish everything had a beautiful pure C API. But C programmers are strictly banned from naming things. Their naming privileges have been revoked, permanently.
creat(...)
Relevant XKCD
Https://xkcd.com/1168/
To quote bash.org (or qdb.us?), you have to talk to tar with a German accent:
where xzf stands for "extrakt ze feil"It's `xaf`, because the modern world is way too complex for simple Germanic rules to solve it.
But GNU tar was never the issue. It's almost completely straight forward, the only problem it has is people confusing the tar file with the target directory. If you use some UNIX tar, you will understand why everybody hates it.
Someone once tried this on me during Friday drinks and I successfully conquered the challenge with "tar --help". The challenger tried in vain to claim that this was not valid, but everyone present agreed that an exit code of zero meant that it was a valid solution.
That is not GNU tar's output. You might wanna make sure your installation is ok.
edit: maybe i missed the joke?
Some drunks in a gnu-shaped echo chamber concluded that the world is gnu-shaped. That's not much a joke, if there is one here. Such presently popular axioms as "unix means linux" or "the userland must be gnu" or "bash is installed" can be shown as poor foundations to reason from by using a unix system that violates all those assumptions. That the XCDD comic did not define what a unix system is is another concern; there are various definitions, some of which would exclude both linux and OpenBSD.
Out of curiosity, what OS are you using?
> maybe i missed the joke?
the bomb specifies only "unix" so you can't assume GNU (which, aha, is Not Unix)
This works with GNU tar, but likely not with tar on other Unix systems.
"tar cf /tmp/a.tar $HOME" would, I guess, work on all POSIX systems.
I seem to remember "tar xvf filename.tar" from the 1990s, I'll try that out. If I'm wrong, I'll be dead before I even notice anything. That's better than dying of cancer or Alzheimer's.
I still do that at least once a week. Along with "tar xzpvf" or more complex invocations like:
So yeah that xkcd is "not funny" to me in that sense. Of course I couldn't tell you pretty much any other use without a man page.
z requires it's compressed with gzip and is likely a GNU extension too (it was j for bzip2 iirc). It's also important to keep f the last because it is parametrized and a filename should follow.
So I'd always go with c (create) instead of x (extract), as the latter assumes an existing tar file (zx or xz even a gzipped tar file too; not sure if it's smart enough to autodetect compress-ed .Z files vs .gz either): with create, higher chances of survival in that xkcd.
Compare these two logs:
Do you really not understand the difference between "you told me to do something, but I can't" and "you just spouted some meaningless gibberish"?The GGP set the benchmark at "returns exit code 0" (for "--help"), and even with XKCD, the term in use is "valid command" which can be interpreted either way.
The rest of your slight is unneccessary, but that's your choice to be nasty.
Like I said, I was operating on a lot of zipped tars. Not sure what you are replying about.
The other commenter already mentioned that the xkcd just said "valid", not return 0 (which to be fair is what the original non xkcd required so I guess fair on the mixup)
Libsodium isn’t a tool or program the average user casually uses. Anyone who actually has to use it in their project even once will remember it.
How often do you forget what Firefox or Gnome are?
That's part of the point, I believe. It's not about being always able to guess the function from first sight. It's also about the function and name serving as mnemonic to each other once you understand how it got named.
I think perhaps the articles argument gets less strong then?
It's claimed grep is "well named" because even though it's not obvious when you first read it, that it being a contraction for "global reg ex print" and hence memorable. I'm not sure the same argument can't be made for libsodium which assuming the reader is familiar with NaCl (the same as the assumption that the previous reader is familiar with regex) then it's an equally memorable name for your crypto library.
There's always a consideration about the context the name is intended and likely to be used in. The article mentions engineering naming and "ibeam", but engineering has it's own technical names an jargon as well. Most people wont know what "4130 tube" means, but people who build bicycle frames or roll cages will - and they're likely to use the less specific term "chromoly" if the don't need to distinguish between 4130 and 4145.
In my head "libsodium" is similar - if you don't know what it (and NaCl) mean, you 100% should keep out of that part of the codebase.
Names fall on a spectrum on this argument. Sodium is not really random because of the use of "salt" on crypto. It's like saying that libsodium is part of your crypto. awk is more random.
The argument goes stronger with projects where the creator seemed to just roll the dice with the name.
Well, "Aho, Weinberger, Kernighan" is not random but entirely unrelated to it's use.
https://en.wikipedia.org/wiki/AWK
One additional complication with grep (and other CLI tools) is that the name itself is part of the day to day UX. It needs to be short, easy to say, and easy to type. With a library the API that is contained within serves the analogous role.
"libsodium" -> "salt" -> "salting is something tangentially related to cryptography" is significantly better as a mnemonic than "awk stands for the author's initials".
Same for grep - with, I guess, the proviso/assumption that you know what regular expression means, which might have been a fair assumption for the sort of people who had command line access to Unix systems in the 70s/80s, but may no longer be valid for developers under 30 who grew up with Windows and were perhaps trained in 6 or 26 week "bootcamps" that didn't have time to cover historical basics like that?
Regular expressions are more of a CS topic (regular languages), though common abbrevs of "re" and "regex" I've only seen in the wild pre and post my formal education in CS.
Yeah, I'd totally expect CS grads, old school Unix sysadmins, and Perl hackers to be fully familiar with Regex. Not so sure I'd expect that from bootcamp front end webdev "grads", self touch game devs, or maybe (I'm not sure?) engineers who have spent their careers in Microsoft dev environments.
> It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name.
Awk is short, easy to pronounce, and difficult to confuse with anything else. It's nearly as perfect as a name can be.
> 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.
You seem to have confused the concept of a "name" with that of a "description". The whole point of names is that they aren't descriptive.
https://en.wikipedia.org/wiki/Arbitrariness#Linguistics
> The whole point of names is that they aren't descriptive
I actually agree with this, but that's exactly the opposite of what TFA is arguing.
So few of us use physical tapes these days, but the "tape archive" (tar) remains ubiquitous.
Not entirely unserious: "awk" is a good name because it is three characters to type "rg" is better than "grep" because it is two fewer characters type
There's a reason why the basic Unix file commands are ls, cp, mv, rm.
They're easy to type on a TTY.
grep is from the ed command "g/re/p" which is g (all lines, short for "1,$") /re/ regular expression to search for, "p" to print the lines.
It still works in vi.
I would if they weren't so outrageously expensive (tapes and tape drives ;))
"It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name."
I never really understood what was "wrong" with the NaCl library that it needed another version that does not have the string "nacl" somewhere in the name
I also remember Google named some heavily promoted non-cryptography project "NaCl" subsequent to the NaCl library's release making any searches for "NaCl" biased toward Google's software
I still use original NaCl, e.g., for CurveDNS, tinysshd, dq and dqcache, not libsodium
You don't need to go that deep into the article. Just - emacs. Of course I know what it is, I had to google the name to find it's EditorMACroS
Pretty sure it stands for Eight Megabytes And Constantly Swapping, a literal description of its function. /s
http://www.catb.org/jargon/html/E/EMACS.html (which also pretty much has your definition, though it calls it "Editing MACroS".)
Well that's jargon in any industry. It makes no sense, you take a minute to learn it, and now it's part of your vocabulary.
At least these kinds of acronyms had utility once upon a time, when typing real estate was valuable and you input commands by hand for hours a day. Typing cat vs concat is hours of productivity save.
It's more that they weren't random. There was a convention, a lineage, or a rule behind them. Modern projects often skip that step entirely and jump straight to branding, even when the thing is just plumbing
The problem with current naming is it now using common names like coffee and it's hard to search for them or relate to them. At least the old Unix naming are kinda unique and sometimes means something. Unlike today.
Yep. Cat, find, git, date, gimp, gnu. All very distinctive, easy to search for
Nitpick: Correct me if wrong but I think cat is catenate not concatenate
IMHO, the best names are the ones that are easiest to type. I have read several accounts of authors choosing names for this reason
I sometimes rename other peoples' executables (cf. libraries), not the ones in the traditional UNIX userland, but the ones with goofy names.^1 I will rename them to something I find easier to type and less annoying. I create symbolic links with the original names if I think they will be required^2
With own software, I give every program a number, the source file is named according to the number and the executable name is a short prefix followed by the number. All names are the same length. I have a text file that lists what each program does if I forget
I put a description in a comment at the top of each source file as a sort of header. Then I can do something like
for a list of descriptions1. Needless to say, Arthur Whitney's software does not get renamed. No need, he gets it
2. I will also rewrite the argument parsing and "usage:" output if it annoys me
The best way to determine what a program does is to read the source. This is one reason I prefer to compile programs from source instead of using "binary packages"
I also think the names that are chosen for so-called "tech" companies are routinely quite silly, but that's another discussion
>developers lost the plot on naming their tools
As a complete outsider it always seemed like the plot had never yet been found to begin with . . .
i think you are misunderstanding the point. with awk, sed, grep they actually hold relevance to the tools whereas a file browser named "zephrus" holds no connection to the actual file browser.
awk is short for awkward, like awkword, for awkwardly manipulating words (text).
[dead]
> 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.
> > 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.
The author is just wrong. Chemistry is fairly jam-packed with various cutesy names either to amuse the authors or because they’re attempting to make an algorithm memorable to the field.
Off the top of my head:
- SHAKE and RATTLE: Bond constraint algorithms.
- CHARMm: An MD package but you’d never guess it from the name
- Amber: Another MD package that you’d never guess from the name.
- So so many acronyms from NMR: COSY, TOCSY, NOESY
The list goes on and on and permeates most of the subfields in one form or another.
If you want really cutesy names, though, look in molecular biology.
> - So so many acronyms from NMR: COSY, TOCSY, NOESY
My favourite: MAS, for magic angle spinning. Because every paper needs a bit of magic.
Scientists are the wrong population to pick if you want people who dislike silly names. They are everywhere because we don’t hate fun, and it does make things memorable. We’re also fond of naming things after people, which is as un-descriptive as it gets.
Also see physics: "quarks," "strange," "charm"
Physics has "Strangeness" and "Charm Quarks"
My own field Materials Engineering has:
"Hardness", "Toughness", Resilience", etc. which all describe different properties.
"Ferromagnetic" or "Ferrimagnetic best believe those are different.
And astrophysics has MACHOs and WIMPs.
and, of course, can't forget the derivatives of position after jerk being snap, crackle, and pop [1] after, you know, Rice Krispies.
[1] https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...
yeah like how about the "sonic hedgehog" protein https://en.wikipedia.org/wiki/Sonic_hedgehog_protein
Also: https://en.wikipedia.org/wiki/Pikachurin
Americium, Einsteinium, Unobtanium also show chemistry isn't so uptight as suggested.
> Unobtanium
I think you mean Unununium.
[dead]
Unobtanium is fiction from the movie Avatar lol
Notoriously bad exposition I might add ("This is unobtanium. This is what we're here for!").
unobtainium predates Avatar https://en.wikipedia.org/wiki/Unobtainium
and at least that exposition makes more sense then the "fountain of youth brain juice" in the sequel, when the humans can literally reincarnate themselves without having to cross interstellar space to do it.
My physics teacher in high school used unobtanium in class and was the first I recall using it. This was way before Core or Avatar. After reading your wiki link, it fit perfectly with the definition of a frictionless, massless pulley use.
It's funny, because I'm one to use movie references in casual conversation like it's nothing, yet my use was definitely not in this case
Avatar was a famously wrong use of the very old term for something that is (no longer) available anywhere.
Unobtanium was a thing in fiction long before Avatar.
America is named after some author writing about a "New World." America is sometimes erroneously used to refer to only one of the states instead of the whole continent.
Einstein doesn't tell me anything, unlike Müller (miller) and Schmied (Schmiede = Forge)
> > > 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.
Lawrencium has entered the chat.
Biology, not chemistry but there's also the Sonic Hedgehog pathway [1]
[1] https://en.wikipedia.org/wiki/Hedgehog_signaling_pathway
Off-topic, but it always amuses me that the sleepy town of Livermore, CA, known locally for its vineyards and an outlet mall, is immortalized in the Periodic Table, instead of the other greater places like New York or Chicago.
Chicago even had the world's first nuclear reactor, but no luck.
Ytterby is an otherwise pretty insignificant small town of 6k inhabitants in Sweden, but it has FOUR elements named after it: yttrium, terbium, ytterbium, and erbium.
Most of your examples are software!
Also SHAKE and RATTLE describe the motion-simulation in the algorithm.
Acronyms are abbreviations for meaningful names.
> Most of your examples are software!
Most of my examples are from computational chemistry, which is software, but (historically) written by chemists.
As one of those chemists (at least before my current work), I feel somewhat qualified to comment on my field and whether it always names things seriously or not.
But if you look around, fun terms are everywhere in chemistry or chemistry-adjacent fields. For example, PALM and STORM (from fluorescence microscopy) were almost certainly chosen because they were easy to remember.
> Also SHAKE and RATTLE describe the motion-simulation in the algorithm.
Not really. SHAKE and RATTLE are bond constraint algorithms to avoid simulating the fast degrees of freedom, typically in solvent.
In molecular dynamics, your time step is effectively set by the fastest degree of freedom (there’s a relationship with the Nyquist theorem here), so it pays to freeze out the vibrations of the O-H bonds in water when you’re simulating a larger system. SHAKE and RATTLE effectively freeze the bond and angle distances near equilibrium while allowing some relaxation.
The rest of the degrees of freedom are typically integrated with a larger time step using a method appropriate for the simulation ensemble (eg: one of the Verlet integrators, a Langevin integrator, etc).
> Acronyms are abbreviations for meaningful names.
Acronyms like XPS, EPR, NMR, etc are like that: dry, short, and meaningful.
But there are a lot that were chosen because they were entertaining to the authors or because they are easy to remember. Even in a technical field, marketing matters.
> Acronyms are abbreviations for meaningful names.
I think often words are added to allow for a memorable name, such as crispr
> When Mojica and Jansen struck up a correspondence, they began tossing around catchy names for the patterns, and on Nov. 21, 2001, they settled on CRISPR—an acronym for Clustered Regularly Interspaced Short Palindromic Repeats.
https://nautil.us/the-unbearable-weirdness-of-crispr-236685/
Biology is another discipline where the author is wrong. See e.g.: https://en.wikipedia.org/wiki/Sonic_hedgehog_protein
Don’t forget the Thagomizer: https://en.wikipedia.org/wiki/Thagomizer
> 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.
But a meteorologist might:
https://en.wikipedia.org/wiki/STEVE
Good job pointing out the logical inconsistencies so succinctly. That article is yet another case of a solution looking for a problem.
I think the author makes a hard distinction between consumer products and infrastructure/engineering products. The Shelby Cobra has a funny name, but its engine is the memorably named V8. The Hoover Dam is a dam, and the Golden Gate Bridge is a bridge.
We can argue about namespace pollution and overly long names, but I think there's a point there. When I look at other profession's jargon, I never have the impression they are catching Pokemon like programmers do.
Except for the ones with Latin and Greek names, but old mistakes die hard and they're not bragging about their intelligibility.
Also the author misses how elements, species and astronomical objects are named. After random places, people, games, fictional characters, etc.
Names are just names. It’s nice if they are kind of unique and have no collisions.
Elements are numbered, species are messy categories to begin with and too numerous, and astronomical objects do have sensible naming[1].
But to me it's still unclear what a good naming culture would look like for programmers.
[1] https://en.wikipedia.org/wiki/Astronomical_naming_convention...
>I think the author makes a hard distinction between consumer products and infrastructure/engineering products.
Which is really funny considering he talks about emacs.
> The Hoover Dam is a dam, and the Golden Gate Bridge is a bridge.
Nothing stops the author from using "Libsodium crypto lib" and "Zephyr RTOS".
> but its engine is the memorably named V8.
You're misremembering. It's the "Windsor V8." Or more specifically the "4.8L Windsor Ford V8."
Thanks, I'm not a car guy. I double checked with Wikipedia, but clearly I don't even know where I'm supposed to look.
Yeah, V8 is the shape of the engine - 8 cylinders in two rows offset at an acute angle (i. e. V-shaped). Likewise a V6 has the same number of cylinders as an inline 6 but performs very differently. There's a handful of different engine shapes - I'm fond of the rotary engines used in early aircraft. Traditionally, the name of an engine was just the year, the manufacturer, and the displacement (like 1965 Ford 352). You often leave off the year and even the manufacturer if it's not required by context.
The Ford 351 is a bit special because there were two different engines made by Ford in the same time period with the same displacement, so they tacked on the city they were manufactured in (Windsor or Cleveland).
Following on on the DoD example, the field of astronomy is infamous for its terrible acronyms: https://lweb.cfa.harvard.edu/~gpetitpas/Links/Astroacro.html
> 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.
In this example, you added "chopper", "patrol boat", and "handgun" to disambiguate them. There wouldn't have been enough context to do so otherwise, which IMHO is more aligned with the point the author was making.
If you were in the middle of a conversation about helicopters with people who knew lots of helicopter models, just saying "Cobra" would probably be fine. But in the software world, there are far too many obscure and new tools that are not at all clear without context. And the context just always happens to be all the dang things. A cutesy name could be any dang thing.
> It's a bad sign when all of the examples in an article don't even agree with the author's point.
I think you're just being selective because you disagree. A better example was:
> “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.”
If we want to cherry pick, your comment has:
> When you open your medicine cabinet
You used the term "medicine cabinet", a term that is not only descriptive, but not branded or jargon. It's standard and doesn't need something new. It's common usage and doesn't need to be disrupted by someone overly proud of a basic thing they made. You didn't call it Wapsooie, a "playful" take on WPSU (Wall-mounted pharmaceutical storage unit) or a MMC (Materia medica cabinet), or a whole host of other cutesy names or even acronyms that you might eventually get to if you were talking about medicine cabinets all day long, or designing or building them.
I mostly agree with the author. Software tools think they're so hilarious. I mean, the Virgil compiler is named "Aeneas" internally. Yet the cli command is "v3c"--Virgil III compiler.
My comment was mostly snarky, but I think the author is oblivious to their own biases and wrong. They even say:
> 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).
"diff" is a good name. There is no sane argument that "awk" conveys anything meaningful about what the tool does. "grep" is utterly opaque until you know what it's an acronym for. The name itself conveys absolutely nothing. "cat" is actively misleading because it is a word, but the tool has nothing to do with felines at all.
The author only likes those names because they're familiar with them, not because they're good names.
> You used the term "medicine cabinet", a term that is not only descriptive, but not branded or jargon. It's standard and doesn't need something new.
Sure. That's because I only have one medicine cabinet.
If I go on homedepot.com and search for medicine cabinets, the bold text is "Glacier Bay", "Zenith", "Kohler", etc.
What's frustrating about this article is that the author doesn't even realize why software packages have these funny names. Let's say I want to make a JavaScript package for parsing command-line arguments. Seems like "argparse" is a pretty clear name for that. Taken. Maybe "cliparse"? Taken. "args", "cli", "options", "argparser", "cli_argparser". Yup, all taken.
Packages need unique names so that package managers and imports can refer to them unambiguously. You can namespace them with the author's name but that just makes it confusing to talk about when two people say "args" but don't realize that one of them is talking about "@some_rando/args" and the other is talking about "@weird_startup/args".
So people just pick cute names. The name is an identifier, not a descriptor.
There is no real problem here, the author is just being cranky.
Military codenames are a bit different; they're deliberately random words, assigned so that no-one can guess the nature of the programme based on the name.
(Companies sometimes do this, too, for internal stuff.)
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)
I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names. A couple rules I’ve internalized are:
- if it’s hard to name, that’s a good sign that you haven’t clearly delineated use case or set of responsibilities for the thing
- best case for a name is that it’s weird and whimsical on first encounter. Then when somebody tells you the meaning/backstory for the name it reveals some deeper meaning/history that makes it really memorable and cements it in your mind
- the single best tech naming thing I’ve encountered (I didn’t come up with it) was the A/B testing team at Spotify naming themselves “ABBA”
> I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names.
As long as you're naming products and features, rather than variables.
oh yeah, definitely. for variables its best to exclusively use obscure unicode.
The winner takes it all!
God this article is 10000% better than the posted one. This is great:
> Names should not describe what you currently think the thing you’re naming is for. Imagine naming your newborn child "Doctor", or "SupportsMeInMyOldAge". Poor kid.
I totally agree with this, and will add that another benefit of whimsical names is discoverability. If your project is named plugin-update-checker and I want to find documentation on it, it's likely going to be buried in a bunch of other irrelevant search results about plugin update checkers in general. If it was called SocketToMe instead, I'm going to find much better search results.
Go.
I suppose it depends on your goals, but that scope restraint can be a good thing.
Do one thing, do it well, and while you're at it call yourself by the thing you do so you remember that's what you ought to be doing. A bit wordy for unix but you get the idea.
> 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.
In mobile telephony, one of the first things new hires are told is “don’t even try to work out what all the acronyms stand for; it won’t help”. You just have eat all the alphabet soup. Worse is that they nest themselves. You can have acronyms where every letter stands for another acronym. Writing a thousand words without using a single noun is easy. And of course all the short ones are overloaded. Is an AP an Application Processor or an Access Point? Depends on which subfield the person you’re talking to is from.
But they’re a necessary evil, since MSISDN is still less cumbersome than Mobile Station International Subscriber Directory Number.
I thought this was a wonderful example of "some things are just intrinsically challenging to represent in your brain":
https://www.youtube.com/watch?v=6ZwWG1nK2fY
Apparently they've found structural differences in the brains of people undergoing London's famously difficult taxi qualification.
I think I saw a video that said people studying for "the knowledge" as it's known report massive fatigue.
The article's complaint (as I read it) is more about incidental load: names that force you to context-switch just to figure out what category of thing you're dealing with
> “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).
I agree. I've worked in places that discourage "cute" names and the result is often things like having to decide between using CoreMainHttp and MainHttpCore. Or worse, two things with exactly the same name, but two different APIs, with projects sometimes taking both as a dependency at the same time. Or even obsolete parts of the org chart encoded into dependency names, like "DataOrgUtils" when the "Data Org" stopped existing several reorgs ago, when our current VP was an intern and nobody else even worked here.
Without some central control of names though, even "cute" ones tend to converge on the same handful eventually: Phoenix (and other classical allusions like Plato's Cave, etc.), Keymaster/MCP (and other 80s childrens' movie references), Simpsons characters, Star {Trek,Wars} references. These are all attractors for the kind of people that tend to be in IT/SWE even if the actual namespace (all possible ASCII-expressable words) is much larger.
Exactly - the author thinks all these tools just materialized fully formed in their software ecosystem instead of surviving years of competition with other, less memorable tools. It takes many years of work, luck, and yes, marketing to get to the point where any of these tools are, and a memorable name can absolutely make the difference between support and oblivion.
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.
> but to claim we have "lost the plot" while holding up names like "awk" is contradictory at best
My argument is that even a name like awk is much more relevant to the people who used this software back then, of course it was not the best way to name it, but at least it held some meaning to it. Unlike modern software, awk and others were not written with the consideration of a wide user-base in mind. Regarding whether we "lost the plot" or not, I believe that we did, because as mentioned, in the 80s there was a current of people who named software conventionally, and up to the 2010s, the names still used to hold some rational even when word-played or combined with cutey names.
> It sounds more like this person just had a personal vendetta against cute sounding names, not against the names being uselessly non-descriptive.
Not at all, I find it quite fun, just unprofessional.
--
Sent by replying to an automated RSS email, via msmtp (light SMTP client, which is unlike firefox, not a consumer product and its name has to do with its function).
> My argument is that even a name like awk is much more relevant to the people who used this software back then, of course it was not the best way to name it, but at least it held some meaning to it. Unlike modern software, awk and others were not written with the consideration of a wide user-base in mind. Regarding whether we "lost the plot" or not, I believe that we did, because as mentioned, in the 80s there was a current of people who named software conventionally, and up to the 2010s, the names still used to hold some rational even when word-played or combined with cutey names.
I don't personally get it. I can see the argument for names that are descriptive, because a descriptive name might be useful. Meanwhile though, a name like awk is only useful if you already happen to know what it stands for, which to me seems a little silly. Relevant? Maybe... But to what end?
> Not at all, I find it quite fun, just unprofessional.
Why do you consider it "unprofessional"? This seems like a cultural thing. For example, in Japan, it seems like it is not unusual to see cute illustrations in otherwise professional contexts. I am not sure there is a standard for professionalism that is actually universal.
Disregarding that, okay, fine: let's say that naming software after irrelevant things is unprofessional. Why should we care?
Software developers have spent at least the past couple decades bucking trends. We went to work at white collar offices wearing khakis and t-shirts, with laptops decked out in stickers. Now I'm not saying this is all software developers, but it is certainly enough that it is a considerably recognizable part of the culture.
Professionalism, in my eyes, is descriptive, not prescriptive. If professional software engineers normally name things with cute nonsense names, then that is professional for our industry.
I can see the usefulness in descriptive names because they serve a purpose, but names that are merely somehow relevant but otherwise don't tell you anything useful seem just as useless as non-sense names, and justifying the distinction with "professionalism" feels odd.
> Sent by replying to an automated RSS email, via msmtp (light SMTP client, which is unlike firefox, not a consumer product and its name has to do with its function).
Note how this also neatly works as a strong argument against descriptive names. RSS? msmtp? We're now drowning in acronyms and initialisms. I don't particularly have anything against these names (I mean, I use msmtp and the name certainly doesn't bother me) but the utility of the name RSS is quite limited and the vast majority of people probably don't really know what it stands for (to my memory it is Really Simple Syndication, but it may as well be just about anything else, since that doesn't help me understand what it is truly useful for.)
But you do hit on an interesting point that probably helps explain to some degree what's going on here: even for small CLI utilities, more often than not programmers doing open source are actually bothering to work on the marketing and deployment of their software. When I was younger a lot of open source was still more decentralized, with many programmers just dropping tarballs periodically and Linux distros (and others) taking care of delivering the software to users in a usable form. Part of trying to deliver a holistic product is having a memorable name.
msmtp may not be developed as a product, but in practice, almost all software is like a product. Someone is a "consumer" of it. (Even if that person is also a producer of it.) People get "sold" on it. (Even if it's free.) How it's marketed definitely depends on the sensibilities of the developers and the target audience but I'd argue almost all software is "marketed" in some form even if it is non-commercial and not packaged like a product. (Even something like GNU's landing pages for things like Coreutils is arguably a very, very light bit of marketing)
The actual truth is software programs that have more care put into marketing are arguably more professional. The professionalism of having a "relevant" name is rather superficial in my eyes, but having concise "marketing" that "sells" your software well to its intended audience and provides good resources for users is professionalism that makes a difference. Likewise, plenty of things delivered more like products do have relevant names! For example, KeePass and SyncThing come to mind immediately.
So whether the next great email server suite is "SMTPMailSuite" or "Stalwart" is mostly immaterial, but I'm not surprised when marketing-concious developers choose memorable names. (Obviously in case of Stalwart, there's a company behind it, so having good marketing is absolutely in their best interest.)
Another downside of a descriptive name is that software evolves over time and a name that is too descriptive could stop being relevant eventually. Off the top of my head it's hard to think of a specific example, but you can see software that evolves this way all the time. (One example on the Linux desktop is how KWin went from being an X11 Window manager to a full-blown display server compositor during the Wayland transition; but that name obviously still works just fine.)
Name it after your favourite football players and functional names will be enforced within the first 3 reviews.
I don't think the core argument is a vendetta against whimsy
Fine, but then my critique moves over: the article should do a better job of conveying what the argument is and why it matters.
It opens with rms complaining about the names in the emacs ecosystem not being descriptive enough. OK. But the author argues (in these comments) that their argument isn't against names that aren't descriptive, it's just that the name ought to be relevant, and the reason why is because that is more professional.
Now I am paraphrasing so maybe I am not understanding the argument correctly, but I don't think that strengthens the case for this at all. If anything, it begs the question... why? (And I'm not sure rms would particularly buy this argument either, given that he beckons from hacker culture and seems perfectly happy to break social conventions. rms does not hit me as someone who is highly 'professional' in a traditional sense. This is not an indictment.)
>“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!
Or had a Kirchner pin inserted.
> 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".
Naming your library "data-testing-library" would be useful... until there's a second one at which point the specific name effectively becomes meaningless.
Case in point: @testing-library (the JS one for React, Vue, etc.)
Besides, this type of overly generic names makes it harder to search relevant stuff, which makes them more annoying to me than silly names.
They also make things hard to talk about. When you mention testing library in an ordinary conversation without @ signs and dashes, people won't know whether you're talking about the concept of a testing library or a specific one.
The other day I was trying to tell someone to use prettier, the specific program, and they thought I meant the generic concept of code formatters
I always get stuck into .NET naming structure Project.Parser.Pcapng, it is great for projects, but it is utterly useless for standalone naming
Some people are passionate about being professional in the sense of doing things competently and expertly. Cuteness is inherently a mental distraction from what you really care about in the craft, which is why it appears tonally inappropriate. The desire to add some sort of cuteness is taken as an indication that the person apparently doesn’t derive enough joy from the workmanship itself. In other words, a lack of caring about and being fulfilled by the actual work, so that you need to add something “fun” on top.
But that's trivially provable to not be true. You can easily be both: dedicated and professional in your work, and fun and flimsy where possible.
I mean, all the funny names of great software in this thread and even OP are a testament to that.
And it’s a lowkey flex. Look, I can be technical wiz and have a sense of humor at the same time!
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
1 for the money 2 for the green 3,4-methylenedioxymethamphetamine
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.
Knowing mysql is a database and not a socket wrench is mildly useful but it's more important that I know whether or not it supports enums.
Spanner is a wrench, or database
The military starts with a cool name, then makes an immediate backronym for launch.
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"
Not at all. You don't name by category, you can name by function or approach. PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL). If your "LLM wrapper" does nothing distinctive worth naming, maybe don't publish it. But if it specifically handles streaming, call it something like "llm-stream-client." If it focuses on prompt templating, "prompt-template-engine." The name encodes the actual value proposition.
I actually stated this on the post, but let me reiterate, I think that naming things in somehow fun way is totally okay as long as it stays relevant to what the tool actually does (you can have this achieved by play wording suffixes (Mongo"DB", Open"SSL", Ma"git" are good examples, all are better than elephant, dog, and beaver).
> PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL).
Indeed. This helps me know that I'm using a database more modern than Ingres. I chose not to use Oracle or SQL Server because they might have predated Ingres.
Just one question: what's Ingres, and why do I care about it? Of course, I don't, which makes Postgres no more useful of a name than "fluffnutz" or "hooxup". That said, over time, I've come to like the name Postgres.
Sometimes names have great value at the beginning of the project. In this case it explains exactly what the project is and will be... That said, marketing decisions like naming a product often don't age well.
You don't need to know what Ingres is. "PostgreSQL" still tells you it's SQL-related, which is infinitely more than "fluffnutz" tells you. And once you learn it's a database, the name reinforces that knowledge forever. Good luck remembering what "fluffnutz" does in 6 months.
That's a really nice mnemonic. I wish I lived in an alternate universe where Postgres was called PostgreSQL so that it was easier to remember. Perhaps if we start using that, it will take over, like how everyone calls the Go project Golang.
When Google introduced the Go language, it was impossible to google for any content related to it. So community quickly pivoted to always saying golang ;)
(At least that's how I remember it as I was "why name a language like that when you know it won't be searchable")
https://www.postgresql.org
https://en.wikipedia.org/wiki/PostgreSQL
I know.
My point is that almost everyone refers to it as Postgres, because they do not actually value the descriptiveness of "PostgreSQL".
> almost everyone refers to it as Postgres, because they do not actually value the descriptiveness of "PostgreSQL".
Also because the original name was, just, "Postgres". Stylized as POSTGRES.
PostgreSQL is an awful neologism (OK it's been around for a while now), and I honestly thought that they had decided to switch back to the original, and clearly superior, name. :) I recall it being under discussion several years back, and I am surprised it did not happen.
I always thought it was because it is more obvious how to pronounce "postgres" than "PostgreSQL".
Sure, but how many LLM streaming clients are out there?
Namespacing, sure. But is "We use gh:someguy/openai/llm-streaming-client to talk to the backend" (x50 similarly cumbersome names in any architecture discussion) really better than "We use Pegasus as our LLM streaming client"?
Nobody says "gh:someguy/openai/llm-streaming-client" in conversation. You say "the streaming client" or "llm-stream" the same way you'd say "Pegasus." But when someone new joins or you're reading code, "llm-stream" is self-documenting. "Pegasus" requires looking it up every single time until you memorize an arbitrary mapping.
This sounds awful, now you'll be reading some documentation or comment about llm-stream where they didn't mention the full namespace, so you have no idea which of the 50 different llm-stream tools they're talking about, and on top of that you can't even search for it online.
> You say "the streaming client"
"Which one?! There are seven popular projects with this exact name on GitHub that have >100K stars; which particular one do you use?"
I promise you, names are not self documenting. Not in any meaningful way.
This is one of those classic examples where things you've already learned are "obvious and intuitive" and new things are "opaque and indistinct".
We can go back and forth with specific examples all day: cat, ls, grep, etc are all famously inscrutable, power shell tried to name everything with a self-documenting name and the results are impossible to memorize. "llm-stream" tells me absolutely nothing without context and if it had context, pegasus would be equally understandable.
> PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL)
How did they pass by "IngresSequel"?
Maybe, and I would definitely prefer this to the random-generic-word practice. "illuminate" is some part of Laravel, but I can't remember what it is, just that "that's not even a noun; they just picked that word for $whatever_crappy_subsystem because it sounds nice" and being even more annoyed at the whole thing because of it.
> 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.
It’s all fun and games until you have to be like “blastoise deleted our database backups”
Well if they used coq, maybe it would not have happened!
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.
Oh, STEM naming… Especially mathematics. How can you tell that a "set" is different from a "group" different from a "manifold" different from a "category"? Then there is a lot of seemingly unrelated things called "space" (they are all actually a topological space, but when studying e. g. vector spaces one might not yet have been into that). "Field" is two absolutely unrelated things in physics and algebra, sometimes these domains even intersect! Linear programming, no real relation to computer programming at all, "programming" used to mean "optimization". Calling stuff after their discoverers might be non-descriptive, but giving a misleadingly descriptive name that also collides is way worse - yet people working with this manage just fine.
>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.
> don't even get me started on people naming their projects random Japanese words
But words help us learn. How many times do you notice a connection between some word from your childhood and an adult concept or place? And they're not random, people choose things because of many hidden reasons, but random is rarely the case.
Many of us love the story behind a word - as shown by many of the comments here reflecting on the cultural history behind our tool names.
> 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 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.
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.
[dead]
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.
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.
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."
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.
At least you weren't the guy hitting a wall when trying to get a testing library integrated because it was named Testacular
Back in college we had an old program used to analyse oscilloscope data named ANAL.
I studied analytic combinatorics in grad school. Had to be sure not to abbreviate it to "anal comb".
At school we called our module analsyn for syntactic analyser. Good times.
When I told a co-worker about https://pypi.org/project/voluptuous/ he immediately searched for the name alone, got really wide-eyed and closed the tab, then told us not to do the same.
There was a markdown library called upskirt, the authors were bullied into renaming it. They called it Misaka, because that's an anime character that uses shorts under her skirt.
I asked to have LaTeX installed at one site, several years ago. The first Google results were eye-opening.
I had a student in one of my LaTeX classes back in the 90s who had a “I lust for latex” T-shirt.
Honestly, I'm not sure which interpretation is more concerning.
What was the first result? Mine is Rakuten Viki, a streaming service focused on Asian dramas that aren’t like what you described.
That was in the 2000s. Google was heavily SFW-ified since.
"First we have to build a Bingo service. See, Bingo knows everyone's name-o..."
- 'Microservices' sketch by Krazam
https://www.youtube.com/watch?v=y8OnoxKotPQ
You can really track the progression of Krazam's career based on what videos he puts out
You will never understand Galactus' pain
If you didn't already know, what do you think a tool called "emacs" does?
Based on the article headlines I've seen over the years, I don't think emacs users know what emacs does except "yes"
Maybe a geekbench from yesteryear. Back in the mists of time it was apocryphally known as "eight megs and continually swapping". But I guess that's a couple of orders of magnitude out nowadays.
It's still to his point:
> 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.
Editor MACroS still has a logic. It isn't just random.
A butterfly valve is a category of thing. The corresponding word for emacs would be "editor." That is entirely descriptive: an editor edits.
Picking a specific butterfly valve randomly from an internet search, I find one called the FNW FNWHPA1LSTG24.
Product types and categories get generic names, specific products often get weird names. It's true in just about every field.
Someone was probably the first to call their valve a butterfly valve.
Emacs can also be taken to be a category of editors. There are multiple emacs-derived editors.
That's as good as random.
I still think of the short-lived Apple eMac when I read it.
Same! I had eMacs in school and loved them, they were my first exposure to the array of characters "emac".
It's funny how they sold that into 2006, with a CRT still
They had to because the RDF was based on CRT technology, originally.
What is RDF in the context of eMacs? I searched but I just get "Resource Description Framework" or "Reality Distortion Field".
[dead]
Uses eight megs of RAM and constantly swaps?
Constantly Swapping its Eight Megabytes, of course.
https://google.com/search?q=Eight+Megabytes++And+Constantly+...
“Emacs Makes Any Computer Slow” is another one I remember from back in the days.
An emergency bootable/rescue tool for Macs!
"Mac OS through email" was what popped into my mind. No idea how that would work.
If you didn't already know, what do you think a tool called a "combine" does?
Combine things? Nope. Its purpose is to separate things...
Its not just the software industry.
More to the point, what does a John Deere S7 600 do, or a 310 G-Tier, or a Z515E ZTrak? Emacs is an editor. That part is descriptive: an editor edits. The product name is not expected to describe what the product is. The general product category is what does that.
> The product name is not expected to describe what the product is.
There are some exceptions, but the agriculture machinery industry has actually gotten pretty good at making the names useful, with reasonable consistency across brands. S7 600: 600 tells that it is a class 6 combine, which is a value farmers understand as it pertains to the combine's capacity. For tractors, the John Deere 8R 230 sees 8 indicate a large row-crop frame, and 230 indicates a 230 HP engine. A New Holland T7.180 is, you guessed it, a medium row-crop frame with a 180 HP engine.
It may look like nothing to outsiders, but there is a lot of useful information encoded in there once you know what to look for.
Useful if you already know the basics of what it is. My point is that "S7 600" by itself doesn't tell you anything if you don't have some knowledge of the product already. The knowledge that it's a combine is separate. Similarly, "emacs" tells you nothing if you don't know it, but the generic term "editor" is descriptive.
Software doesn't generally encode product attributes into the name the way 230 means 230 horsepower and such, but that's because software doesn't really have things like that to put in the name in the first place. Most software doesn't have specific variants like that, and software that does is almost always differentiated on feature set rather than numbers.
Software often puts the version in the name. Which is the same as the S7 designation in the case of said combine. S7 is just a restyled S7x0 series combine, which was the successor to the S6x0 series.
It's not a perfect system. Before the S6x0 was the 9x70STS series, after the 9x60STS series, and the 9x50STS series. You can find a version number in there, albeit not a perfectly sequential one. Although that's nothing new. Windows 3.1 turned 3.11, 95, 98. iOS 17 turned 26. You get the picture.
Technically it's a "combine harvester" as far as I know, which is more intuitive. Though in practice everyone calls it a "combine".
Technically it is "combine". Originally it was known as a "combined harvester-thresher", which is maybe what you're thinking of, but that was soon shortened to "combine" and it has stuck ever since.
"Combine harvester" showed up in some places later where context was needed to figure out what "combine" means, but it was seemingly only for context. "Combined harvester-thresher harvester" is pointlessly redundant.
I'm conflicted because you're not entirely wrong (that it's not just the software industry), but the name is because the combine combines steps that used to be separate.
It's not actually badly named.
> I'm conflicted
That's why I chose that specific example! What fun would there be in you not having to think about it?
> If you didn't already know, what do you think a tool called "emacs" does?
Hmm, this looks like a nonsense word, but sometimes words look like nonsense when you write them backwards, maybe it's a scame?
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.
I used GIMP before I ever used Photoshop. My experience was the opposite. I think that means the UIs are different, but there is no one that is objectively better, it's just a matter of what your expectations are, which are set by whatever you learned first.
As for CMYK support: why do designers even need to use this? Sure, not every RGB is the same, and it took some while before we even got sRGB as some standard, but the same goes for CMYK: every printer has its own profile. I had the displeasure of trying to get the CMYK profile of a "professional" printing company that only accepted files in CMYK, and they didn't even know which profile their printers used. Ideally you would send a RGB file including the display profile your screen uses, and then the printing facility converts that to whatever CMYK they need.
Of course there are also special colors or effects outside of RGB/CMYK that you might want to use when printing something, that's something else.
GIMP has god horrid UX, there's no way it could have eaten Adobes anything. There's lineage of FOSS apps that stick by the "we're not X, we're different from X." mantra.
The discomfort, frustration and unintuitiveness you're feeling from using our app? It's just you!
No, that's not bad design and bad UX! its simply because we are different! We aren't X (Photoshop), we just do things differently here!".
GIMP is quintessential example of this.
For what it's worth, we're trying to encourage more feedback from designers and users to make GIMP better. We have a public repo dedicated to UX/UI discussions: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues
We've implemented a number of items from the issue posts once consensus was reached, and we hope more people will participate and help improve GIMP further.
Do you have examples of bad UX in recent Gimp versions that's not simply "no time to improve it" (still mostly volunteer project)?
I believe Gimp could never enter the professional circles because it's internals are too tied to one, single colour model (RGB).
Professionals in many fields use tools with very bad UI/UX.
I agree GIMP is a bad name, but is it really a 'solid' competitor to Photoshop? My impression has been that it was never close to being competitive on features. I've only used either of them very briefly so I may be wildly wrong though.
IIRC, it was too expensive to make Gimp support non-RGB color spaces needed for professional image editing.
I use it semi-regularly and it does a great job for me, and most of UX is clear and obvious (high DPI support is lacking). But I haven't used Photoshop since the 90s (or Aldus PhotoStyler before it was acquired by Adobe ;)).
I think it could have been -- which is to say, I think a better name earlier on could have well been what could have gotten more contributors etc etc. Network effects and such.
> which could have perhaps eaten Adobe's lunch MANY years ago.
That "perhaps" is doing a whole lot of work in that sentence. GIMP has never, even now, been a serious competitor to Adobe's products for professionals. To suggest that if they simply had a better name they would be the top dog is laughable.
Wait until you learn about Git. ;)
Be careful. The language police have already got rid of "master". They were eyeing up gimp for a takeover or rename but I don't think it got very far. Perhaps all their energy was spent on removing the slavery from git.
Sorry, I do have to say "touch grass" here.
It's not about "me being personally offended."
It's about professionalism. It's a tradeoff. I see both sides of getting rid of e.g. "master;" but GIMP is so well beyond. Even if you make the argument that it's not offensive you're still stuck with a name that absolutely connotes "this thing is not going to be good at things."
If I have to "wait and learn about it" then it's not the same, now is it?
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.
“Have you seen the new show? It's on Tubu. It's literally on Heebee. It's on Poodee with ads. It's literally on Dippy. You can probably find it on Weeno. Dude it's on Gumpy. It's a Pheebo original. It's on Poob. You can watch it on Poob. You can go to Poob and watch it. Log onto Poob right now. Go to Poob. Dive into Poob. You can Poob it. It's on Poob. Poob has it for you. Poob has it for you.”
— <https://knowyourmeme.com/memes/poob-has-it-for-you>
Unfortunately this article misses the worst failure of naming: name collisions.
Yeah, if we followed this advice every language would have four different packages named http-client.
Indeed, however I would point out that the approach of naming things after elements or processes ex. Sodium results in not-so-unique names in certain contexts. Ex. if you're working in a lab that deals with the element or process, then confusion can result with colleagues.
> 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"...
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.
1. https://youtu.be/y8OnoxKotPQ?si=QkI-TPStI9I4RtAB&t=33
To be honest, `awk` that the author references to as a good name, is not. It's just the initials of authors, which does not convey anything about what the tool does. It's yet another cognitive tax.
And I would go further, the extremely shortened names in Linux and other places is problematic too, given that most terminals now allow name completion on tab.
Now? Tab completion has been a thing for decades.
https://en.wikipedia.org/wiki/Command-line_completion
Tab completion being a thing does not take away from short, memorable names being easier to use. You'd likely end up typing more on average, due to multiple programs sharing the first few letters of their name
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?
COBOL. Now there's a sensible name.
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.
I really gotta hand it to "wget" for picking a good name for a program that gets things from the web.
>> 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.
"names conveyed purpose or origin.": no they don't. If I use the authors example of the two people talking: as if saying "BASIC" instead of "Cobra" explained the meaning anything better to a person who never used BASIC.
I've been programming for 15 years+ and never used basic due to my age and I never know, until today, that BASIC stands for "Beginner’s All-purpose Symbolic Instruction Code".
Why? Because I don't need to know and it doesn't make the usage of BASIC anything different.
The author should read up on the https://en.wikipedia.org/wiki/Sonic_hedgehog_protein or maybe https://en.wikipedia.org/wiki/Boaty_McBoatface both of which are actually scientifically important things.
Amiga famously had a custom ASIC called "Fat Gary" https://en.wikipedia.org/wiki/Amiga_custom_chips
I really could go on about this. Names are only useful for distinct identification. They need to be distinct within their domain. Otherwise they're just an index into a list.
Sonic hedgehog is a terrible example this case. Researchers literally had to tell parents their children had mutations in the "sonic hedgehog gene." The scientific community recognized this was a problem and it's a widely-known controversy. It's cited as an example of bad naming in medical ethics discussions.
Boaty McBoatface? officials overrode the vote to name it after David Attenborough. The actual research submarine got the joke name. Again, this proves my point.
Fat Gary was an internal chip designation that never needed to be public-facing. Perfectly fine.
"Names are only for distinct identification" if efficiency was not at a question. Why use worse identifiers when better ones cost the same?
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 "<>".
End of the day you know what it means or you don't. I agree it's helpful when a name is descriptive, but there's no helping the fact that you're going to have to learn the names of things that aren't obvious. Purely utilitarian names would constantly collide.
I also think they overestimate how distinct terminology is in other fields. Even their example of the I-beam is also known as an H beam or an RSJ depending on who you're talking to. I don't find it hard to imagine a mechanic referring to one of their specialty tools by the name of its manufacturer, either.
Regardless, the battle was lost before it started. There has never been good consistent descriptive naming as standard in computing; there was no plot to lose.
Just love of whimsy is part of it, not denying it. But other parts of it are that a generation or two on, a lot of the straightforward names are taken.
(Also, I wouldn't say `awk` or even `grep` are good examples (as the OP admits) -- they were definitely chosen for whimsky, with, if not actually backronyms, still acronyms deisgned for whimsy).
And another part of it is that so many people now have dreams of commercializing their product, so you need a "brand" name. (I guarantee the namers of the tools had no designs on commecializing grep or awk). (I have little sympathy for this one, but it's the world).
I do agree with OP it is a problem for accessibility. Newcomers who haven't already memorized the mangagerie have a lot to figure out; some people's brains work differently than others and it's easier or harder for some people to remember these arbitrary names naturally; I'd guess it can be especially hard for non-native English speakers, but maybe it's all Greek (ha!) to them anyway, so.
When i have tried to name things plain though, I often have trouble -- we want something clear, but also relatively short (especially if it's going to be in namespace or other identifier names and be typed a lot!) -- and not already taken in popular consciousness or the package managers we'll need etc, and often I have trouble finding such!
Just name everything Phoenix.
(The joke here is: look up how many _major_ software projects have been named Phoenix at some point. It's a lot.)
Yes. If someone complains, just rename it to Firebird.
"Gemini" seems to be the modern Phoenix
the problem with technical software names is that they are either too long, too pointless, do not die when underlying tool goes through re-incarnation(looking at you angular) or worse, too important to be wasted on a lesser quality project (looking at you react-router).
in my company, we have a tool whose technical name was four word long, and has just as much cognitive load as any technical name.
one of my biggest contribution to that project was to Name it.i gave it a simple name, with zero relation to tech or any software
and suddenly our PMs, Managers, Users can pronounce it and can actually type it correctly and of course recall it's name flawlessly.
so, at least from my experience, having a small, easy to pronounce name is more important than having technical name.
Moreover having a name with all of the qualities is definitely desirable, but there are many projects in world and not that great names. and many Great names (looking at you, Vue.js) are either already taken or beyond my naming skills
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.
pty is a Pseudo TeletYpe (aka, terminal emulator). It's 50-year-old word.
ptyxis is a word based on the 'pty' base, because it's not the only pty program.
It's a nearly-unique name, which is very good for the task of "discovering what it is".
It’s a solid terminal, but could they have chosen a worse name?
There's another comment that points out that a g-le search will pick up few false positives (disclaimer, have not tried myself). So the initial 'WTF' gives way to 'well, ok, I see what you are trying to do'.
This is a norm to the point of being a rule for Elm packages. The names are things like elm-csv, elm-json-decode-pipeline, elm-iso8601-date-strings. There's a strong preference in the community to name a package for exactly what it does, and differentiate on the author namespace if needed e.g. you may choose among coreygirard/elm-nonempty-list, mgold/elm-nonempty-list, and v-nys/elm-nonempty-list depending on which meets your needs best
I remember working on a ruby project and running into some problem with our env setup tool and just hitting "could not find nokogiri" (or an error to that effect) over and over and getting a little mad that I had to read this cutesypoo not-at-all descriptive name over and over while failing to get a danged website to run.
---
To be sure, there are in-the-know parts of all the package names I just listed: what does JSON stand for? What does CSV stand for. What is the ISO and what is 8601? I guess the idea there is the descriptiveness ends at the edge of the language; the package name is too short a field to explain Javascript Object Notation, Comma Separated Values, or the ~~International Standards Organization~~ ok actually it's from "isos" meaning "same" date format.
I’m glad you cited Ruby, as it’s definitely the exact opposite of what you said about elm. Every damn gem has an idiotic cutesy name. I think it’s one reason why every mature Rails project I’ve seen in the corporate world has direct dependencies on five or six different http client wrappers. New developers would look in the Gemfile, find no “http” anything, then google “ruby gem http client” and, since that happens to be a diverse category, eventually developers will find and add all such libraries.
I’m hoping that with AI, maybe this will be less common, because an AI agent should easily see that you have, say, Faraday installed already, and not bring in the noob magnet that is httparty.
And forty years ago, I was using a tool called Brief, which was a product from UnderWare. I was also using a librarian named Marian.
Robert Preston, is that you?
> 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.
Yes and no. The Navy has or had a lot of code in JOVIAL, Jules's Own Version of the International Algorithmic Language. SNOBOL goes a long way back.
> There are only two hard things in Computer Science: cache invalidation and naming things.
> -- Phil Karlton
- https://skeptics.stackexchange.com/questions/19836/has-phil-...
- https://martinfowler.com/bliki/TwoHardThings.html
> 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.
Well if they work for a drug company they will say “Let’s call this phlogistotheremone but sell it under the name Zyphyrax so that doctors and patients will refer to the same medication by different names.”
>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.
Odd? Modern? I started working professionally in 2005 and everything had silly names. The DNS server was named athena instead of c302r5s1 or whatever building/room/rack/position name. I once rebooted a server that had an uptime of 12 years, so it had been running since 1993... it indeed had a silly name. Everything had silly names, usually types of things had a theme.
>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.
How about piranha? aqua regia? Up/Down/Strange/Charm quarks? Gluons? Like a third of the elements named after people or places.
Curium, Einsteinium, Fermium, Mendelevium, Nobelium, Lawrencium, Rutherfordium, Seaborgium, Bohrium, Meitnerium, Roentgenium, Copernicium, Flerovium, Oganesson -- I guess none of these people were named Steve, but you get the point
These tendencies are OLD and EVERYWHERE. IUPAC names are just a convenient way to serialize data.
One issue with package naming is competition. One of the great things about OSS or software in general is people can take inspiration from other projects that do the same thing. Personally I've ran into deciding which casting library to use
- runtypes - https://github.com/runtypes/runtypes
- zod - https://zod.dev/
- ajv - https://ajv.js.org/
AJV and runtypes use the naming convention that the article suggestions. It's named is derived from how it's used. Zod on the other hand seems to come from left field.
Personally, I built a simple caster called "ShallowCaster" before choosing to move to a library as things got move complex but I think a problem is that as competition increases the "generic" naming becomes more difficult to find.
I suppose an option is to include the author name for each package such as "json casting from google" or "@google/json-casting" this way all packages can use the descriptive naming while not conflicting
Great post and I think this extends to machine learning names, although not that severe. Maybe it all started with Adam. When I say “I used Adam for optimization” this means I used a random opaque thing for optimization. If I say “I used an ADAptive Moment estimation based optimizer” it becomes more transparent. Using human names or random nouns has been a trend. Lora, Sora, Dora, Bert, Bart, Robert, Roberta, Dall-e, Dino, Sam… With varying capitalization for each letter. Even the Transformer. What does it transform exactly? But it gets worse. Here is a list of architectures that may replace Transformers [0]: Linformer, Longformer, Reformer, Performer, Griffin, BigBird, Mamba, Jamba... What’s going on?
[0]https://huggingface.co/blog/ProCreations/transformers-are-ge...
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
We had this debate at my company and the end result was a ban on “random” service names.
So we ended up with “auth service” instead of something like “Galactus”. The problem of course is that “auth service” isn’t searchable in our monorepo and it was a nightmare to find or discuss any info or references to the service itself. Now imagine if docker was called “container manager”. Good luck googling that and disentangling it from all the search results.
The value of a name doesn’t come from it being self-explanatory but rather from it being a pseudo-unique identifier. The small cognitive tax of remembering it serves as a shared bookmark between people that you can refer to when discussing or speaking to others about it - whether we’re talking about docker, Linux, or another person.
It's especially fun once the service is superseded. Guess which one of these services handles MAC address allocation and storage: macaddr_db or atom-util?
"There's a repo called Beyonder. That's got to be what came after Galactus."
Worse is the Git UI, where random English words that seem to have a clear meaning in the context of source control don't do at all what you think they do, or five different things, or are really just a bunch of other commands wrapped together for less typing (like "pull").
I would rather have fantasy names than wrong names.
The author isn’t comparing apples with apples.
“Butterfly valve” is the name for a type of widget.
There are many instances of “butterfly valve”, some of which will have strange brand names.
Just like there are many “web frameworks”, each with weird and wonderful names (“Django”, “Rails”, “Spring” etc.)
We’re really not that different.
> 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.
> Same thing applies to other fields like chemical engineering [...]. 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.
I realize this isn't chemistry, but aren't there like 15 elements that are named after people (Curium, Einsteinium, etc) another handful named after places (Americium, Tennessine, etc).
Also, a bunch are named after Norse and Greek gods like Thorium, Titanium, Plutonium.
The article also goes to talk about the Hoover Dam, but it's not like the government is immune to this either. We just had Operation Warp Speed which doesn't tell you anything about what that program did
The author is vastly overestimating the general legibility and familiarity of things they happen to know well and are used to.
Boring names are also very generic, by definition, and thus often harder to remember. Especially when there are 10 other similar tools. Is it sql-validator, sql-schema-validator, schema-validate, db-validator, or god knows what else?
Edit: I am in favor of better “sub titles” / descriptive slugs / and so on. As well as names that are a hybrid of creative and descriptive. Sqlalchemy is a good example.
Why isn’t there a command line utility called “whatisthis” with a standard protocol that allows tools to give a brief description of what they are?
It could be extended to package managers as well. E.g “pip whatisthis foo_baz”.
Shit we should create this…
The real trick is getting just enough meaning into the name to be helpful, while keeping it distinct. SQLAlchemy is a great example.
I called by zsh bookmark tool `tutu`, my idea was to make it sound like what it does.
- It helps you go TO places - The main command is `tu` because it is short, a homophone of "to", and wasn't already taken - Additional commands `tutu` (which does a `pushd` instead of `cd`) and `untu` (which is just a wrapper around `popd`) are short, memorable, and pronouncable.
All of those naming decisions were made with ergonomics in mind.
Was I successful? I like it. A few other people are using it and seem to like it, too.
To the extent that I was, I think it's because the name is meaningful enough while remaining distinct.
https://github.com/daotoad/tutu
> Why isn’t there a command line utility called “whatisthis” with a standard protocol that allows tools to give a brief description of what they are?
Cheekily, man?
Hah good point. Maybe v1 just pulls the first few lines from man.
This might not be exactly what you mean by a CLI app called "whatisthis", but I have been using cheat.sh and the pattern below for a few years. It works really well!
curl cheat.sh/grep # fetches brief grep cheat sheet
I'm not sure arguing in favor of alphabet soup naming is any better. At least we ended up with semantic versioning, because originally it had also been just an expression of marketing and creativity. I don't understand even slightly why he blames Google in the article. He also forgot to propose what he believes Google should have been named. Search Engine? AWCSS? And the fact that he'd be fine with Viper and Cobra if they had backronyms points to the ridiculousness of the whole article. I'm genuinely most fascinated by how he accomplished writing that much text without the nonsense of his position dawning on him.
Past projects of mine.
Oh and https://lerc.itch.io/namesarehardpart5The examples given for real world things The Golden Gate Bridge and The Hoover Dam, are instances of things. Things that the class of which they belong is old enough that Dam and Bridge are not new words.
If you are making new things you need a new name. Software is inherently new because computers have been in wide use for only a few decades. Instances of software rarely even get names, just numbers, with project names or nicknames attached. I'd be willing to bet both The Golden Gate Bridge and the Hoover dam had project names or nicknames.
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.
it's kafkaesque
Is Kafka (as in Apache Kafka) a good name?
I believe the phrase I'm looking for is hallelujah!
The naming culture is beyond salvation. It crossed the line when things went from 'We invented this word to name our thing.' to 'We fused the concept of breakfast muffins in cat pictures meme to the previous application of the open source tool to name our abstract thing more accurately. That's why it's called 7Mermaids.'
I remember when Yahoo had to spend a fortune on commercials asking "Do you Yahoo?!" It seems that old business lesson was completely forgotten.
> 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!)
https://www.chm.bris.ac.uk/sillymolecules/sillymols.htm
And don't isomers share their name? And isotopes don't change the name either, I think?
Except protium, deuterium and tritium
<tangent>
What is it with a number of blogs recently that have turned off normal right-click behavior, and probably related, the scroll behavior is awful.
This is one, and as soon as I scroll on my work high powered Macbook and it's not smooth, I'm out.
[OP] Can you please doublecheck? Nothing should affect right-click behavior or scroll, if you're experiencing it, it's probably from your end.
You are correct, my apologies. It was at work where we have NannyWare of various sorts, so it might have been that. Working fine from home; thanks for confirming.
I am more frustrated by the fact browsers allow such manipulation such as this and some clipboard operations.
are you guys naming your products?
We have an internal name and our product name. Internal names start as something that describes the project/repo/tool. Then within 18 months the name no longer makes sense so we rename it to some random name - state names, lake names, presidents, mountains, etc. It's just a placeholder.
The public facing product name is a compromise of marketing, trademark, and what gets approved by the CEO. Even the company name might change in startup world. No joke: the startup next door had to change their name because it was too masculine, and they realized more than half their projected market was women.
This is the way, you name things random words devoid of all connection to software because you don't want to confuse people later when the scope grows or changes.
Well so in the beginning we only supported email notifications which is why it's called EmailServ but over time it grew into a robust and pretty general queueing service so now it handles all our background task processing. Sending emails is actually handled by EmailWorker but EmailServ still supports its original API which now uses EmailWorker behind the scenes if you prefer that.
I noticed this with companies first, though at least it always made some sort of sense that a meaningless name would make it easier to pivot.
If your name is "The Database Company", but at some point find you'd rather do Blockchain and then later AI, the name might be an obstacle.
If you call yourself "Gworp" in the first place, you'll have no such problem.
(Though in not sure if "Mt Gox" aka "Magic: The Gathering Online Exchange" would be a positive or negative example for that)
Mt. Gox is a name change done after the fact, it's just reinterpreting the original initials.
As they say in physics: color and charm may change, but up and down are forever.
> 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
Would it be better if it was this:
> We’re using ConfigurationManager for configuration management, which feeds into CLI for the CLI, and then WebSocketHandler handles our WebSocket connections, PermissionManager manages permissions, all through JobQueue for our job queue
I think the author makes the opposite point of intended)
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.
And you've spotted why normal, regular, simple, natural, real mathematics is so hard for people to grok at first glance.
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.
Does Julia registry have active moderation? Otherwise I'd expect to see 99 different variations of DifferentialEquations.jl
Yes, but it's fairly light-touch moderation. Newly registered first packages go through some automatic checks, and if they pass all those checks they are put on a 3-day waiting period for community to give feedback or raise objections to the package, and then at the end of the 3-day period, if nobody blocks it, the package is registered.
One of the automatic checks is a name similarity check, and if the name is too similar to an existing name, then the package is blocked from being auto-merged. At that point, someone will look at it, and there'll be a discussion on whether or not the name is okay. A lot of the time, the response is just "this is a false positive" and the package is greenlit. Other times, there's a discussion on whether or not the name is acceptable, and some alternative suggestions are given.
_______________
There was a little episode recently where someone tried to register a package with the same name as an existing package, but with two letters tacked onto the end of the name. Their package was just a fork of an existing package, but with a minor patch applied becuase they were frustrated that maintainers of the existing package weren't responding to pull requests.
The system automatically flagged the name, and the person was initially upset that they couldn't just register their fork, but within a couple hours we tracked down a maintainer to fix the existing package, and then we added this person as a maintainer to the original package so that they could review and accept pull requests to the package themselves. I think this ended up being a better solution for everyone involved.
I believe one of the things that prompted stallman to give that talk was the inclusion of the lsp client "eglot" in emacs. Eglot i think is short for emacs polyglot.
The most idiomatic name, lsp-mode, was taken by another package. Stallman wanted to find another name but no one seemed to care as much as he did. I think one name he suggested in its place at one point was "code-parse" or something like that.
This essay is not consistent. They ramble between company names Google ( which is a great name ) and tools like AWK which is not descriptive at all but a good name.
But I do share his pain with onboarding when I joined Humungous Entertainment the tools or systems were called Sputm, Phlegm, Mucus, SPIT. There might have been a Bile. :-)
Have a Stoolap https://github.com/stoolap/stoolap
It's good to see it's written in Rust with full Acid compliance...
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.
A lot of the issue has to do with marketing. Some people name their tool for the pizazz it might generate and gain them fame or it's an actual company motivation. Instead of a hammer is a hammer and a heavy hammer should be named "heavy_hammer".
EDIT: I just noticed that the marketing angle is mentioned in the article.
Codenames are good identifiers when lots of projects exist. There are more software projects now than EVER.
I welcome Splorg, Chizzel, Rapunzel, Brap, Titoid, and Chungus - I don't care as long as it's good.
I agree, some names that come to mind are Celery and Windows. But there are always silly names. I like Plan 9, an OS named after an Ed Wood B movie. Its sibling, Inferno is full of puns and references to Dante Alighieri's Divine Comedy. Its corporate dullards who insist that neutral boring is appealing to most and I again agree but its not a hard rule for me.
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.
Why does nobody in SF say "I am going via the San Francisco-Oakland Bay Bridge", but shortens it to just the "Bay Bridge"? This is the reason some bridges get a nice name (like Golden Gate), and some are strictly utilitarian (like SF-Oakland Bay).
And I am sure there are other "Bay Bridges" in the world too.
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).
Why does it have to be all or nothing? How about a clever name or two for marketing that stands out and doesn't get lost in a sentence "I'm not asking you to search, I'm asking you to use the search command" but not obnoxiously over done where everything is named after some Norse god or some other silliness.
Thete is no way to give descriptive names unless it is a single centralized system. Names need to be consistent, this is the main requirement for a good set of names. When the whole set is consistent, individual names can be nearly arbitrary, it won't matter much.
I have developed a language for writing structured queries. Based on this article, I have decided to call it SQL.
Calling it Sequel would have been made it easier to pronounce. I think I'll just pronounce it that way in my mind.
There was never a plot to follow; if there isn't a better name for an editor than "vi" (because "ed" is already taken) then maybe they should try getting rid of verbs too to give it more "refreshed" branding.
I just want an editor! Not a "viitor". Not an "emacsitor". Those aren't even words!!!
Imagine calling your firm "Commerical Firm". Would this even be allowed?
How do conference-room names fare in this view? My current company names them after football teams or local landmarks. But I heard about someone who used to work somewhere that named theirs after WWII battles, which was awkward for the Japanese guy they interviewed in one of them.
There is a place I agree with this: human anatomy. I find eileiter/oviduct superior to Fallopian tube.
The two hardest things in software engineering: cache invalidation, naming things, and off-by-one errors.
Descriptive naming absolutely helps at first contact, especially when you’re scanning a dependency list or onboarding someone new. No argument there. But in practice, names stop carrying meaning pretty quickly anyway
There are many different tools that attempt to solve the same problem, with varying levels of competency.
They can't all use the same name. If you want to build a better alternative to an existing solution, you need to choose a different name, this leads to names being arbitrary.
And the species of flies "Phthiria relativitae" was named as a pun on "Theory of relativity" and "Reissa roni" after "Rice-A-Roni".
I am highly sympathetic to this sentiment, but I think it's hard to name things in software because a) it's easy for the obvious names to get overloaded and b) many of the things we are dealing with are basically abstract relationships with arbitrary properties.
This drives me crazy because I use dmenu to launch things, and every time I want to launch a subsonic client I'm like "blueberry? Wayshin... Weish... Fei... FEISHIN!"
Just call it "subsonicfeishin" or something at least!
"Chatgpt... Mc... CODEX!"
It's nuts.
> The cognitive tax
> Every obscure name is a transaction cost levied on every developer who encounters it.
It’s not a mental burden, it’s a cognitive tax. Moreover it’s a transaction cost? Levied on people? Which loads their RAM?
Where’s the simple everyday English?
Anyway. We used MongoDB for a good while.
Love this:
> 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.
RMS, of GNU's not Unix fame, has opinions on proper naming?
I like good old names like the foobar2000 audio player. Iconic.
- Starts with lowercase.
- Means nothing.
- Good player.
https://www.foobar2000.org/
I'd prefer developers make up names for their project to make it easier to search, or at least use a very uncommon word. Gradle is a good example.
I almost completely disagree with this post. The only thing I can consider that you should probably avoid embarrassing names.
A descriptive name is terrible if you're slightly off. Or if the library gets repurposed. Or if the project doesn't turn out how you expected but it's still helpful. With everything going on, a nonsense name forces people to learn about it instead of having them guess at it from a three word description that might be misleading.
The author probably never had a project where something got named the oscilloscope-controller but there's no oscilloscope in sight, but we used to have one and then we tweaked a few things and now it runs something else and but the name was everywhere.
And all of these are abstract concepts. Getting data from point A to point B. FIFO? It's an acronym. Pipe? Doesn't really suggest it can buffer data. Buffer? Queue? Both sound like they might slow down data. Precise technical names would be good, but then the chances the purpose changes goes up!
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 can't call my new formula translation language FORTRAN because it's been taken, as have many other names. So now to avoid collisions, it's named after my cat.
FIVETRAN is a weird name for a cat, but I guess it prevents mix-ups at the vet.
By the author's standard, macOS and iOS has some pretty much perfect program names, I suppose:
App Store, Mail, Photos, Music, Books, Podcasts etc.
R followed the long standing tradition of being one letter off as it was derived from S. And its creators were Robert & Ross.
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.
I think it's because if you always used a descriptive name you'd end up with multiple tools with the same name.
I was just discussing this today funny enough. How long until someone goes for broke and just names their app "peepee poopoo"?
I strongly agree with this. And what bothers me more than obscure or meaningless names like Viper are silly and embarrassing names like Hunchentoot. Names like that sometimes cause people to dismiss good software. It’s like using Comic Sans in a serious research paper.
One area of the sciences does partly use names like this, and that is biology. Biologists do sometimes name a species after a famous person, as in the louse Strigiphilus garylarsoni:
https://en.wikipedia.org/wiki/Strigiphilus_garylarsoni
I agree. One recent example is in the Zig community a popular tool for benchmarking is "poop" [1] (Performance Optimizer Observation Platform). It could have easily been "pop" (Performance Observation Platform) and been cute enough without being intentionally cringe. Every time I see Zig now I think about "poop".
[1]: https://github.com/andrewrk/poop
Even for consumer products - I'd rather have Mozilla Mail and Microsoft Mail instead of Outlook and Thunderbird. But marketing must market, dammit.
My favorite - "Tech without an interesting name (TWAIN)" for scanner/ imaging drivers from the 90s.
Fun party game: Ask people if they know ChatGPT. When they inevitably say "yes", ask what GPT stands for.
By this standard, ChatGPT is an excellent name: it's a generative pre-trained transformer that chats with you.
https://youtube.com/watch?v=y8OnoxKotPQ
It's literally just as hard to name things descriptively as it is to name them cutely.
Im jealous of people able to write multi-paragraph text for such a simple thought.
The two hardest things to do in computer science is knowing when to invalidate cache and how to name things.
And off-by-one errors.
First it was racehorses. Then it was prescription medications. Then software.
I hope this goes no further.
The craft beer names though.
I'll offer a recent example. Gigantic Brewing Company in Portland, OR: The Cat Ate My Stash & Pissed On the Christmas Tree
Style is IPA - American.
Idk about open source tools, but internal corporate things have codenames for good reasons.
I'm happy to see this post, it's something that bugs me every time I have to learn a new tool with a name that's neither A. unique to the project AND B. doesn't describe the project.
For example Zola and Hugo, static site generators - great, unique words that has no other meaning to me but the generator. The only other Hugo I know is a character in Bob's Burgers. But choosing random dictionary words like Avocado or Spice or whatever makes it completely transparent against my existing knowledge and now I have the mental lookup issue the author describes.
The other day a HN user was commenting "NAT, aka IP masquerading... (proceeds to keep re-using the term)". IME no one in the industry says "IP masquerading" unless your entire org and vendors are on Linux. Just call it NAT, we know what you mean. This a Linuxism and should be avoided!
Let's hit up Britannica.com on the word:
> a party at which people wear masks and often costumes
> a way of appearing or behaving that is not true or real
> to pretend to be someone or something else
I guess? I guess we are "pretending to be the peer IP when actually we are the LAN IP". But to me it's just nonsense. It's capital T Translating one IP to another for the sake of routing, drop the weird social implications.
> The only other Hugo I know is a character in Bob's Burgers.
Really? It's a very common name, including certain Victor and Boss.
https://en.wikipedia.org/wiki/Hugo_(name)
Genes and species are also sometimes given ridiculous names.
- VTL-O2
- Forth
- Grep
- CVS (I'm not an American but you can relate)
- Clang
Altough MS products can be as opaque if not more. And let's not talk about IBM...
I remember a trend of randomly dropping vowels started with flickr.
> Your HTTP client, cli utility helper, whatever library is not a consumer product.
I'm not sure how the author came to this conclusion.
At any rate, programmers aren't any worse about this than mathematicians. Just replace [fictional name] with some foreign word or philosophical term that's justified with the most insane mental gymnastics you've ever heard of. Given some historical native speaker of Latin, do you think they're going to know what a matrix is for? No, because the word means "uterus". There is no connection to "tabular shorthand of linear transformations."
I think it's clear the author is writing this to vent frustration, but I think they've misidentified the actual problem:
> http-request-validator is infinitely superior to “zephyr” when someone is scanning dependencies at 2 AM debugging a production incident.
My jaw hit the floor reading this. The idea there are people out there debugging codebases without knowing something as foundational as the dependencies is beyond absurd to me. That's insane and horrifying, overshadowing pretty much the entire blog post. Does anyone else live like this? How do you tolerate these conditions? Why would you tolerate these conditions?
I still think ICQ was the greatest application name ever.
Is fun not allowed anymore? In the past 3 days I've seen posts and comments on HN saying that:
- everything in interfaces should be useful, decorative icons are bad
- presentation slides should not use animations
- now fun name are forbidden too apparently
What the fuck?
> No chemist wakes up and decides to call it “Steve” because Steve is a funny name
Do you want to enter the discussion on how physicists named quarks?
- Almost everything on blogs and HN are opinions, so don't take things things too seriously
- Fun and humour are subjective, and a substantial part derives from novelty and subvertin expectations. It's hard to make something fun for an audience that has already seen such dozens of times.
- The audience('s background and expectations) is diverse and varies with time. So what's considered "fun" is audience specific and often cyclical.
the whole post/topic has amazing engagement farming potential
the correct response should be the "that's bait" GIF/meme (from the aptly namee Fury Road documentary)
https://imgur.com/gallery/thats-bait-FOwZ77O
You're right, when looking into it it's just flameware in the end
I like to mock the current meta as being coca cola driven.
> 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.
Ummmmm...
https://en.wikipedia.org/wiki/List_of_chemical_compounds_wit...
"You sure 'bout dat? You sure 'bout dat?"
My favorite: there's a protein called "sonic hedgehog" that's essential to animal embryonic development. (All of the "hedgehog" family proteins would cause fruit flies to take on a spiky appearance when mutated, hence the name.) When chemists synthesized a drug that suppresses SHH protein's action, they named it "robotnikinin".
The Drosophila people had the best naming schemes. I really wish we kept up the whimsy of gene names. One I enjoy is RING; "really interesting new gene". I have always said if I find a gene of interest, I'd call it RUNG.
"windowpane" was my first thought :) such a lovely play on the "-ane" suffix
I find the remark that we give things names more as a word play than purpose.... kind of amusing? Like, of course people will find a way to play with the tools they have. And in programming, that is often words. Because what else would it be?
By far the worst aspect of the nerd ecosystem is the odd belief that pops up every so often that names should matter. In every ecosystem, there is usually some odd idea that it is only in their world that people abuse this.
Just skim through that list of things that are unexpectedly named after people. Sure, you can get upset about Shell's sort not having any relation to shells. Or Bloom's filter not having a phase where the data "blooms" into use. But you would have the same issue with French drains. Or how gaslighting has nothing to do with lighting things on fire using gas and the affect that will have.
Honestly, I think this would be a fun list to just keep going. Akin to the old Chuck Norris joke generators.
> 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? Have you specced a microprocessor lately? Seen what pharmaceuticals are called? How polymer compound materials get named?
The "Raptor Lake" codename in microprocessors is internal, the product ships with systematic designation. Engineers spec chips by model numbers that encode generation, tier, and performance class.
In Pharmaceuticals, Doctors prescribe "sildenafil," not "Viagra." The generic name describes chemical structure. Brand names are marketing for consumers, not professional nomenclature.
Mythology in chemistry/astronomy has centuries of legacy and connects to human cultural history. Calling an element "Titanium" after Titans carries weight. Calling a SQL replicator "Marmot" connects to... what, exactly? A weekend at the zoo?
"Raptor Lake" isn't an internal codename, it's very much external as it's what Intel actively referred to that generation as. How's a non-geek shopping for a PC going to know if it's better or worse than "Lunar Lake" or "Alder Lake"? Maybe they just think their machine is shipping with some game where your giant dinosaur bird thing has to stop off for a quick drink to regain energy.
But in any case, this isn't the real travesty with these names. It's that they're reusing existing common words. The article hates on "google" when actually it's a fantastic name - if you googled it when it was introduced, all the results were about what you wanted. By comparison, Alphabet is an awful name, because if you search for Alphabet only a tiny subset of the results are going to be useful to you.
Naming schemes in consumer marketing serve a function. They are easily identifiable, unique, and memorable. All of these properties serve to identify the thing by associating a unique name with a unique set of services/function/effects on use.
Medical and chemical terminology is built on the history of latinate terms and compounds whose simples follow the same pattern. Latinate terms, I might add, which reference mythical, fantastical, or unusual things. Consider the planet Mercury, for example. The only difference? The centuries of time it took for scientific evolution to turn these unique names into a taxonomical language with its own logic.
There is no such taxonomy for computer science. But in the course of the evolution of such a taxonomy, it will be built out of the mess of names like the ones we like to use for our programs and tools like Rust, Ocaml (notice combination of interesting and technical), git, npm, bun, ada, scipy, etc etc.
> Doctors prescribe "sildenafil," not "Viagra".
Depends on the location, I guess. I've had doctors prescribe trade names, which I don't understand if there are alternatives with the same dosage, route of administration and similar inactive ingredients. Not even talking about the "do not substitute" prescriptions which are also based on dubious information most of the time.
As for "sildenafil" - I don't think generic names are usually meaningful. Usually the suffix relates to the category of the drug, but the first letters seem as random as the letters in trade names. I could imagine a world where the generic name is viagrafil and the trade name is Silden.
Generic drug names don’t describe chemical structure, they allude to purpose but that’s all. ‘-afil’ is used to apply to a particular class of drugs, although when it was discovered, ‘sildenafil’ was the only example of that class, so it didn’t mean anything already.
This is like having the first tool of a particular type come along and call itself ‘Mosaic’ and then someone makes another tool of the same kind and calls it ‘Mozilla’.
But the names we're talking about are the ones used to market software to users? I don't see how the same logic doesn't apply
Brand name pharmaceuticals are sort of a different thing. Brand names must comply with the naming guidelines of the FDA, European Medicines Agency, and HealthCanda simultaneously. In practice, this makes it tricky to use actual words. So my companies adopt an 'empty vessel' naming approach. The empty vessels are nonsense words that (1) invoke an emotion (wegovy is a good example), (2) can be trademarked, and (3) it can survive brand pressure.
Like GMail addresses, all the good names are taken.
The Sonic Hedgehog gene would like a word.
> Your HTTP client, cli utility helper, whatever library is not a consumer product.
> (...) Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste
Devs who build FOSS utilities owe you, or the industry, absolutely nothing. As someone who lists Noam Chomsky under "Some works I recommend engaging with", you sure seem to think capitalists are entitled to people's free work, to the point where you start making demands.
I could not disagree more. If you say "Ben told Mary that he would work with Scott on Jeff's house on Tuesday, but that Amy preferred Wednesday", that sentence carries a lot of meaning for the speaker and listener because those "names" have meaning to both parties. Nobody would tolerate the descriptive alternative: "General Contracting Company Owner told General Contracting Company Secretary that he would work with General Contracting Company Hired Hand #4 on Customer #22's house on Tuesday but Customer #22 Spouse preferred Wednesday".
Irrelevant. LLMs know all the names. In 1 year they will be doing all the SSHing and terminaling.
Quickly: name the AVX2 instructions that the compiler emits for math calculations
The names have always been quirky, but the new names mostly seem to be chosen for some branding / marketing reason (which I don't like). You can basically put "[any noun] javascript library" into google and find something. The space is so saturated that the names have become more and more disconnected from what they describe. Someone should go create labubu.js so people are less inclined to do so themselves. You can benchmark it with matcha (not to be confused with matcha.css).
This author has lost the plot.
Sometimes "branded" names are a good thing.
For example, naming some application modules strictly after what they do is super tedious, and uses words that are already reserved, therefore creating ambiguous nomenclature. Maybe I have various sort of permissions in my system but naming that particular permission system some greek god name creates a clear and shared meaning across the team (both business and technical), and mind you that that's what communication is all about - a shared meaning. Nothing else.
P.S. (I'm deliberately not going into discussion about bad things with that approach)
"...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... "
I would not mind the command names whose etymology was complex or inspired, if the README files would do a better job of giving context and function. Even though I have a wide set of wheelhouses in computer systems, I frequently encounter README files that still leaves me saying "Huh?". I shouldn't have to google three levels down before I get a clue.
This is a pretty tangential to the article but Debian is just about the worst there is here. An application will be given a friendly name in an attempt to make it more user friendly. (eg: gedit is called "Text Editor") But, there is often no way whatsoever to map the friendly name back to the actual package name. Want to uninstall gedit? Well if you don't already know what it's called, good luck.
Preach! The worst excuse I hear is "but if we have a meaningless name it can't become inaccurate later when the project changes!".
Uhm yeah. That's like saying "if stab myself to death now I can't die of dementia in old age!"
Edit: look, it's here! https://news.ycombinator.com/item?id=46237390
Modern web developers: "Oh I just use Gulp, Jenkins, Babel, Yarn, Bower, Grunt, Slurp, Vite, and Rollup"
Me: slowly backs away in disgust
I hate when the steal sci fi concepts and I get falsely excited hearing about say Dyson sphere cold fusion drones.
I’m 100% with OP on this. So many posts on the front page have names like “Hamburger — a tool for doing a thing.” These names are neither memorable nor distinctive, good luck trying to look them up later.
why is this stupid ai-generated text on hn?
I have agreed with this for at least a decade. Name your things in a way related to what they do.
What does chef do? Garden? Pig? Burp?
Nonsense.
This reads like an extensive, and frankly exhausting, rationalisation of a personal preference. Personal preferences are fine, I have my own. But please stop thinking they apply universally.
Laravel works better than Rails-but-PHP. Ruby on Rails beats Opinionated-One-Person-Stack-Using-Ruby and I'm fine with the name Ruby as well.
I shall name my next product larmn in honour of OP.
Wait till you work in a corporate environment, where Project Fuzzy Mustard triggered a violation of the ElastoFish metric in the Yellow Hills subsystem, leading to a Code Mild Lavender with a side of Pink Sprinkles.
I worked in one that had lettuce, tomato and celery in the stack.
We have a boulangerie and a fromagerie
I need scissors! 61!
I no shit once worked on 'Project Magenta Lobster'.
That's nothing, we have an initiative called Pink Glove.
I agree for internal names but disagree for public software/external names.
I disagree for public/open-source software, because: So many kinds of software actually have good names. Yes they use mythical names but with the similar function or relatedness.
Meanwhile, I agree for internal names, because: So many (legacy) code I worked with had terrible naming. This goes beyond only the names themselves but also their capitalization or consistency. I kid you not, in a $FAANG company I saw "SpidermanActivity" and "BatmanActivity" on a system that is used by Tier-1 services' on-calls.
> (Although this thing was not a Tier-1 service, it was not also completely Tier-2 either, as it was actively supporting operations of Tier-1 services, depending on the incident, a downtime could cause significant problems...)
Imagine you are trying to make sense of a large system, which has maybe tens of dependencies and as much of dependents, you are also trying to remember which API was Spiderman and how it related to the business at all...
More on the naming conventions, the horrible case of acronyms (which spans outside of software engineering) and PMs creating polls/surveys for "fun names for our new shiny thing that does X but we don't wanna call it that".
Going even lower-levels, engineers themselves are not careful. I had way too many CDK stacks named with not only varying dash vs underscore differences, but also with subtle "case-sensitivity" differences.
Each year, I am solving issues of Java devs' issues. Some of being "but it works on my machine" type of problems. And significant percentage of that is most developers use a Mac & macOS. Hence the filesystem is case-insensitive by default. But the deployment target & CI being a Linux, filesystem is case-sensitive. As you can see here, The camel-case combined with inattentiveness can simply cause many hours of waste.
> It's a plague.
Yes, there is an AI slop, but there is also human sloppiness too. I am quite happy with LLMs/GenAI that it is able to catch and capture these and less prone to make such sloppiness in the first place. (As it being a "predictive-text engine", next word suggestion is a clone of existing copy of historically occurring words)
At the same time, amount of "hallucinations" for various acronyms are staggering. Obviously I cannot expect otherwise. Even as a human, if I am missing the context, I would be either confused or plug-in something I already know...
"“We’re using confman for configuration management, which feeds into climan for the CLI, and then wsconn handles our WebSocket connections, permgr manages permissions, all through jqueue for our job queue”"
This is better? Is this Highlander, there can only be one of each thing? What about variations of those tools... cman2? confman? cfigmgr? Naming projects, and hence tools, is often just as much about namespacing as meaning. There _will_ be more than one of most non-trivial tools/projects, and not every configuration manager can be called "confman" (if that's even really a "good" name").
And part of it _is_ connecting utility to an "appelation": calling "your MIT-licensed file parser with 45 GitHub stars" just "parser" practically gaurantees you'll never get that 50th star, because there are already a bunch of "parser" projects and there is no reason for someone to ever find yours.
"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."
No they don't, because you're _not_ doing that processing every time. Just like "grep" makes perfect sense _now_ because you've used it forever, once you're working on a project then something like "cobra" immediately maps to "the cli library". It might take a secon the first couple times, but humans are good at this internalizing kind of abstraction, and programmers are damn amazing at it.
The unix tools example is really terrible. "I used grep to examine the confs in etc and then cat to combine them before processing with sed and awk and tarballed the output to be curl'ed to the webdav server." Those are only intuitive because you know them already. "sed" for "stream editor"? Come on, it's not called that because it's a good name. Why not strmed, or even streameditor?. Simple, actually intuitive. It's because 'sed' was the bare minimum to be a short as possible while being unique and just memorable enough. Awk is an even better counter-example to the article's claim: it's just names, makes no sense! Has literally _nothing_ to do with what it does.
"the Golden Gate Bridge tells you it spans the Golden Gate strait."
Umm, no it doesn't tell you that. Does the Brooklyn Bridge span the Brooklyn strait? George Washinton Bridge? Bridges are not exclusively named by that which they span, and software is not exclusively named after exactly what it does.
counterpoints:
pascal, eiffel, ada, C, APL, dylan
JavaScript
Some interesting commentary:
> InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?
> Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.
C
C post increment
See sharp
Once again proving that there are two very hard problems in software engineering: Naming things, cache invalidation, and off-by-one errors.
There is actually a good reason not mentioned, not to name tools by their purpose:
- the purpose will change
Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else.
Or your "login-page-config-service" tool may eventually do more than just logins.
Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particular thing which may or may not be correct anymore.
Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.
Project names should be unique enough to allow them becoming their Id,
- It allows to find the project.
- It allows the project to change, extend it's scope or narrow it.
Having an Id is really important, making that Id related to the project's original intention is nice, but secondary. (as long as it doesn't change enough that it becomes misleading).
"purpose will change" argument actually proves the opposite point. When a tool's scope expands beyond its name, the descriptive name tells you something went wrong. But even if so, if you have to rename "login-page-config-service" to "auth-config-service" it is not really a big deal, renaming will be much cheaper if you're renaming to descriptive names. Most importantly though, I wouldn't optimize to avoid renaming (happens once, maybe twice in a project's lifetime) by making discovery hard (happens every single time someone encounters the tool).
> renaming will be much cheaper if you're renaming to descriptive names
Idk, renaming things that shipped is a PITA.
Say you wanted to rename `fish` to `a-decent-shell`. - Packages in all distros would need to be renamed. - Configuration for all systems using/having fish would need to change. - Scripts would need to change, from the shebang to the contents if necessary. - Users would need to understand that they now need to search documentation using the new name. - Documentation would need to be migrated to new domains, sed-replaced, and reviewed.
All this migration would require some synchronized, multi-step process across multiple distros and deployments.
I'd rather have a name that works as an Id.
> Say you wanted to rename `fish` to `a-decent-shell`
You just made my argument. Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
Every cost you listed [distro packages, configs, scripts, docs, domain] exists whether you rename to something descriptive OR another random word. The migration pain is identical. "Fish" → "decent-shell" costs the same as "fish" → "zephyr." My argument was that this renaming won't be necessary if you started by picking up the proper name at the first place, and it's very unlikely to have the need to rename it. We shouldn't be optimizing to avoid renaming. That's trading a rare maintenance event for permanent cognitive overhead.
> Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
No, it's just because the goddamn string Id appears in way too many places and you can't sed-replace the entire world at once. It doesn't matter if the string was cute, fancy, or you found it to be a good name.
> We shouldn't be optimizing to avoid renaming.
> you should get it right from the start.
This is also optimizing for not renaming, just in a different way; also, you just said renaming was cheap, so which is it?
[dead]
A good reason to use arbitrary code names before assigning a more helpful name upon release of something deemed to now be generally usable, beyond developers with caveats.
I like this approach. Use a cute, fun, memorable name internally for stuff getting off the ground. Once it becomes user facing, the internal name becomes a fun note on Wikipedia and the world sees the actual calculated name.
Is it just me or the website is completely unreadable? Black text on a dark-gray background
>Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste
>Reserve the creative names for end-user products where branding matters. For infrastructure, tools, and libraries, choose clarity. Every time.
Ah yes the software I am giving away for free must go easy on the minds of the poor VCs and business drones who are extracting value from it.
This just feels like an old man yelling at clouds, trying to convince himself that the grass in greener in the other field.
> 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 happens every day. In every scientific field there is a technical name and then the name everyone remembers. Nobody will understand if I speak about ENSG00000164690, but if I say it's the Sonic HedgeHog gene then it starts to make sense, because funny names are memorable.
> awk (Aho, Weinberger, Kernighan; the creators’ initials)
I'd like to see anyone try to defend how using the creator's initials in a tool name describe its function. Unless you researched the tool's history, there is no way to know that.
Yet another "why the tools I use are the best and the tools you use suck", with a weird focus on naming instead of function.
One more reason why Windows is superior to OS X.
What are some examples of names that Windows does better than macOS and vice versa?
I've always though iOS naming was pretty logical - Calculator, Notes, Messages, Mail, Health, Clock, Calendar, Photos, Contacts, Maps, Settings. They're all named as if they're the reference implementation and everything else is 3rd party.
Under Windows we have Notepad, Paint, Terminal / Command Prompt. Word and Excel are likely household names so it's tough to ask a random person who's never heard of them to describe their purpose. But they did have "Clipchamp" which was a pretty dumb program IMO.
Here's a potential reference for Windows app naming conventions in modern Windows: https://windows-11.fandom.com/wiki/List_of_apps
Windows is pretty bad, but I have to give the dark pattern award to macOS for being overbloated with services. Especially if you're an average Joe; wouldn't you assume that AppleTV plays your video files, and Apple Music focuses on playing your MP3s? How are you supposed to know that Quicktime is the less intrusive option? It's hidden in a glut of inscrutable, outdated apps like Automator, 3D Chess and the graphing calculator everyone opens by accident. At least Windows knows to hide the cruft apps from the Start menu.
It's gotten to the point with macOS that I don't think my parents could use it. They use Windows just fine without knowing the difference between Terminal and Command Prompt, but macOS would be a mnemonic shoggoth too far.
[dead]
[dead]
LMAO ok dude, don't like it? fork it and change the name. The author has a DEEP misunderstanding of the science of human language, not surprised he's a Chomskyite.
Rule of thumb, disregard every post that uses the phrase "context switching"