> 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.)
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?
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.
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’.
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.
"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.
1. Heavy dependency on Github. AKA Microsoft owns much of the golang ecosystem. Not just the source... The package distribution as well!
2. Many packages are referencing a git (short!) commit hash instead of a version. It still boggles my mind that this is an acceptable practice. Not to mention that git tags can be deleted and recreated... A pinnacle of secure package distribution practices.
3. Stuff like ambiguous imports because apparently nothing enforces proper go.mod files? They are not packages to be compiled after all, they're just repos with some conventional structure (optional)...
Mind you, this is popular production-grade software...
I think this is much worse than even node packages, let alone bundler and rubygems...
1. GitHub dominance is a social phenomenon, not a technical requirement. The go.mod file you linked references ~14 different Git hosts other than GitHub. Go's design doesn't create this centralization; it merely reflects where developers choose to host code.
2. You complain about commit hashes while simultaneously noting that tags can be deleted and recreated. Hashes are precisely the solution to mutable tags. The "short hash" concern is a red herring; Git uses sufficient entropy that collisions are not a practical concern for dependency resolution.
As for "secure package distribution," go.sum files verify files verify consistent downloads. What additional security do you believe centralized registries provide?
3. Can you provide a concrete example of an ambiguous import you've encountered? I'm not familiar enough with Go to understand this criticism.
Exactly. This 'social phenomenon' should have been taken into account when designing a packaging system so that the language's ecosystem does not end up entirely dependent on Microsoft due to 'social reasons'.
> The go.mod file you linked references ~14 different Git hosts
Of which the non-github ones account to what... 15% of the deps in the file?
> You complain about commit hashes while simultaneously noting that tags can be deleted and recreated
Yes. Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call. Once a version has been tagged, the only viable choice must be to pull that version and push a new higher version.
> As for "secure package distribution," go.sum files verify files verify consistent downloads
Based on git's hash.
> Git uses sufficient entropy that collisions are not a practical concern
Unless crafted by an adversary? Git's sha1 hashes are not a security tool and must not be used in place of code signing.
They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes. Rubygems has the ability to reference git repos. It's always a pain to update these compared to other semver deps -- you have to go to github and do a comparison between the old and new hashes to try and deduce whether bumping this will break you.
> Can you provide a concrete example of an ambiguous import you've encountered
Thank you for the reply. I'm designing a platform that will include dependency resolution and hosting, so I value input on these issues.
> This 'social phenomenon' should have been taken into account when designing a packaging system
I'm unsure how this would be accomplished in practice without banning certain Git hosts, which seems untenable. Even Maven/Gradle ecosystems concentrate around a few major repositories (Maven Central, JCenter historically). This appears to be an inherent social dynamic rather than a solvable design problem.
> Of which the non-github ones account to what... 15% of the deps
Same question: what's the solution? Developers publish where it's easiest and most popular, creating a positive feedback loop. I don't see how package system design can prevent this.
> Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call
Agreed on both counts. However, how do we enforce immutability beyond operational controls? Even systems with "immutable" version policies ultimately rely on the registry operator honouring that policy. The only technical guarantee would be embedding content hashes alongside version numbers (which is effectively what go.sum does, albeit awkwardly).
Sidebar: how should we handle vulnerable versions? Allow pulling with warnings, or remove them entirely?
> Git's sha1 hashes are not a security tool and must not be used in place of code signing
Fair point. I was under the impression that Git had moved to SHA-256, but it seems there's no practical way to use it yet. While Git moved to a hardened SHA-1 implementation (not vulnerable to the SHAttered attack) in v2.13.0, SHA-1 remains weak for security purposes [1]. The transition to SHA-256 has been in the works for some time, but as of 2022 it appears to be a partial implementation with no support from major Git hosts [2].
What would ideal package security look like to you?
> They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes
Completely agree. Repository references are useful for development and testing, but painful in production. I avoid them in published packages.
> See end of linked go.mod
Thank you, I see it now. I'm still deeply unfamiliar with Go but this feels like a legitimate criticism.
Glancing at github.com/tencentcloud/tencentcloud-sdk-go: is this import ambiguous because there's no top-level `go.mod`? If so, that feels like a significant oversight. I'm a fan of monorepos myself but I'm surprised Go doesn't have better support for them. I'll be doing some research to understand this better.
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).
reply