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.
replies(4):
- 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.
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.
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).
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).
- 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
Really? Have you specced a microprocessor lately? Seen what pharmaceuticals are called? How polymer compound materials get named?
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.
I'm charmed by the lack of truth in this beautiful sentence. Top of mind for me, at least.
"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.
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?
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.
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"?
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.
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.
> 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.
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.
- 'Microservices' sketch by Krazam
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.
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.
> 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).
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.
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.
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:
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.
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.
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.
>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.
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.
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.
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?
'pedes
Glook
Fitznik
Plops
Gyralight
I wanted a new tower defence game: So I made one
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.
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.
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.
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.
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.
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.
> 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'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?
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.
"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.
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.
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".
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 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.
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.
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.
> 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?
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.
Quickly: name the AVX2 instructions that the compiler emits for math calculations
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
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.
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.
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.
C post increment
See sharp
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…
Rule of thumb, disregard every post that uses the phrase "context switching"
> 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?
I feel like this is approximately the third time I'm learning this.
The argument goes stronger with projects where the creator seemed to just roll the dice with the name.
grep almost has an onomatopoeic nature to it… like, it sounds like you are grabbing or ripping the patterns out of the file, right?
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.
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...
Names are just names. It’s nice if they are kind of unique and have no collisions.
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.
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.
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 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.
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".
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.
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
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.
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.
Chicago even had the world's first nuclear reactor, but no luck.
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.
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.
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.
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.
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.
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.
sed is just an example, of course, the author's point doesn't hold much weight for many (most?) users globally.
But they’re a necessary evil, since MSISDN is still less cumbersome than Mobile Station International Subscriber Directory Number.
— This comment brought to you via Firefox, which obviously from its name, is a web browser.
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.
> 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.
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.
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
https://groups.google.com/d/msg/alt.folklore.computers/HAWoZ...
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".
https://google.com/search?q=Eight+Megabytes++And+Constantly+...
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/
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
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)
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.
Nothing stops the author from using "Libsodium crypto lib" and "Zephyr RTOS".
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.
https://web.archive.org/web/20081206105906/http://www.noah.o...
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.
https://en.wikipedia.org/wiki/BitchX less so.
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.
- 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”
> -- Phil Karlton
- https://skeptics.stackexchange.com/questions/19836/has-phil-...
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.
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-...
"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 believe this makes much ado about nothing.
>>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 worked in finance – we gave our models names that endeared us to them. My favorite is a coworker naming his model "beefhammer".
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.
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.
Just call it "subsonicfeishin" or something at least!
"Chatgpt... Mc... CODEX!"
It's nuts.
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.
I mean, all the funny names of great software in this thread and even OP are a testament to that.
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'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"...
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 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 ;)).
(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")
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.
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.
My own field Materials Engineering has:
"Hardness", "Toughness", Resilience", etc. which all describe different properties.
"Ferromagnetic" or "Ferrimagnetic best believe those are different.
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.
And I am sure there are other "Bay Bridges" in the world too.
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).
Or Gtk even: Gnu-is-not-Unix Image Manipulation Program ToolKit (later changed to refer to Gnome instead of Gimp I believe).
it stands for 'Copy and Convert' and was renamed to `dd` only because `cc` was reserved for the C compiler!
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.
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!
Besides, this type of overly generic names makes it harder to search relevant stuff, which makes them more annoying to me than silly names.
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.
[1] https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...
$ 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 $?
1My 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).
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)
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
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.
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.)
I personally think that's a pretty good idea for coming up with better names instead of cute names now.
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).
Einstein doesn't tell me anything, unlike Müller (miller) and Schmied (Schmiede = Forge)
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."
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
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!)
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.
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.
That's why you find most of software engineering department in Computer Science Faculty or School, not in the Faculty of Engineering.
So at my last job, we called our monolith anubis. It always brought joy when someone asked for an explanation.
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.
edit: maybe i missed the joke?
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.
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.
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.
I would rather have fantasy names than wrong names.
- 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?
the correct response should be the "that's bait" GIF/meme (from the aptly namee Fury Road documentary)
- 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.
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.
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 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)
> 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.
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.
[0]https://huggingface.co/blog/ProCreations/transformers-are-ge...