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