Posted by todsacerdoti 3 days ago
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.
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.
Funny how we never confirm our hypothesis that "checks out".
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.
it stands for 'Copy and Convert' and was renamed to `dd` only because `cc` was reserved for the C compiler!
I believe this makes much ado about nothing.
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.
The stupid content tracker.
Still one of my favourite names.
(Even Solaris, *BSDs already started including GNU tools, compilers...)
CVS (noticed already mentioned by a sibling comment) is just an abbreviation.
Python - well Monty Python
The entire premise of the OP is simply wrong.
Or Gtk even: Gnu-is-not-Unix Image Manipulation Program ToolKit (later changed to refer to Gnome instead of Gimp I believe).
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.
Traditionally, according to folklore? "Delete disk" or "destroy data". (Because it was commonly used to write raw disk blocks.)
https://web.archive.org/web/20081206105906/http://www.noah.o...
https://en.wikipedia.org/wiki/BitchX less so.
"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."https://groups.google.com/d/msg/alt.folklore.computers/HAWoZ...
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.
I personally think that's a pretty good idea for coming up with better names instead of cute names now.
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.
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.
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.
Like Microsoft Word?
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.
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-...
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).
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...
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.
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.
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.
Ironically, much like sodium itself, a substance of which the author seemingly possesses too much of.
The stdlib still contains `un.rb` though: https://github.com/ruby/ruby/blob/d428d086c23219090d68eb2d02...
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.
grep almost has an onomatopoeic nature to it… like, it sounds like you are grabbing or ripping the patterns out of the file, right?
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.
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.
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
Funny that they are still some of the most efficient and powerful interfaces.
I feel like this is approximately the third time I'm learning this.
sed is just an example, of course, the author's point doesn't hold much weight for many (most?) users globally.
How often do you forget what Firefox or Gnome are?
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.
The argument goes stronger with projects where the creator seemed to just roll the dice with the name.
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.
Https://xkcd.com/1168/
tar xzf file.tgz
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.
$ tar --help
tar: unknown option -- -
usage: tar {crtux}[014578beFfHhjLmNOoPpqsvwXZz]
[blocking-factor | format | archive | replstr]
[-C directory] [-I file] [file ...]
tar {-crtux} [-014578eHhjLmNOoPpqvwXZz] [-b blocking-factor]
[-C directory] [-F format] [-f archive] [-I file]
[-s replstr] [file ...]
$ echo $?
1edit: maybe i missed the joke?
the bomb specifies only "unix" so you can't assume GNU (which, aha, is Not Unix)
"tar cf /tmp/a.tar $HOME" would, I guess, work on all POSIX systems.
tar cvf - -C /foo/bar baz | zstd > foo.tar.zstd tar zxvf
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.
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.
tar xvzf file.name
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.
The rest of your slight is unneccessary, but that's your choice to be nasty.
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
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.
http://www.catb.org/jargon/html/E/EMACS.html (which also pretty much has your definition, though it calls it "Editing MACroS".)
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.
"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.
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
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
As a complete outsider it always seemed like the plot had never yet been found to begin with . . .
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.
I actually agree with this, but that's exactly the opposite of what TFA is arguing.
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.
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.
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.
My own field Materials Engineering has:
"Hardness", "Toughness", Resilience", etc. which all describe different properties.
"Ferromagnetic" or "Ferrimagnetic best believe those are different.
[1] https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...
I think you mean Unununium.
Notoriously bad exposition I might add ("This is unobtanium. This is what we're here for!").
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.
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
Einstein doesn't tell me anything, unlike Müller (miller) and Schmied (Schmiede = Forge)
Lawrencium has entered the chat.
[1] https://en.wikipedia.org/wiki/Hedgehog_signaling_pathway
Chicago even had the world's first nuclear reactor, but no luck.
Also SHAKE and RATTLE describe the motion-simulation in the algorithm.
Acronyms are abbreviations for meaningful names.
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.
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/
But a meteorologist might:
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.
Names are just names. It’s nice if they are kind of unique and have no collisions.
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...
Which is really funny considering he talks about emacs.
Nothing stops the author from using "Libsodium crypto lib" and "Zephyr RTOS".
You're misremembering. It's the "Windsor V8." Or more specifically the "4.8L Windsor Ford V8."
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).
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.
> 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.
(Companies sometimes do this, too, for internal stuff.)
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)
- 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”
As long as you're naming products and features, rather than variables.
> 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.
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.
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.
But they’re a necessary evil, since MSISDN is still less cumbersome than Mobile Station International Subscriber Directory Number.
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.
> 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).
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.
— This comment brought to you via Firefox, which obviously from its name, is a web browser.
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).
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.)
>>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!
I'm charmed by the lack of truth in this beautiful sentence. Top of mind for me, at least.
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".
Besides, this type of overly generic names makes it harder to search relevant stuff, which makes them more annoying to me than silly names.
I mean, all the funny names of great software in this thread and even OP are a testament to that.