This comment specifically argues on this part:

Perhaps I was not very clear, but I didn’t claim that any of these are good-enough names. Unlike many other disciplines, computer scientists never considered the problem of naming seriously, ideally, as I claimed in the previous post, we would have compound terms or namespaces for naming (so when another person develop another global regular expression print, it won’t have collision with grep). Instead, my claim was that any of these names are still much better than “dogfind” or whatever anime character someone would pick to name their regex implementation after. Awk is indeed a bad name, but at least people back then were able to relate it to something, even if it was the author initials.

The claim was that even other scientists maintain some strange naming. But you can notice from the linked Wikipedia links how they indicate that they’re “unusual”, this should be enough to explain how this case differs from what we have in software development, which is the norm. Here’s my response to one of the comments that mentioned Sonic hedgehog and some other bad names:

My response:

Again, we had much better technology to do much more effectively than that.

Now what all these objections have in common? They’re all defending the status quo by pointing to edge cases, internal designations, or acknowledged mistakes in other fields. But renaming is hard!“ (So get it right initially.) ”But scope changes!" (That’s a feature, not a bug, the name should constrain scope.) None of these arguments address the core problem: the cumulative cognitive tax imposed on every developer who encounters your arbitrarily-named tool. They’re optimizing for the creator’s convenience at shipping time while ignoring the compound interest of confusion paid by every user thereafter.

I’m not insisting every tool be named with Germanic compound precision. I’m asking for a return to the basic professional standard that existed (roughly) before we decided software engineering was too cool for clarity.

The bar is remarkably low:

• Does the name give any hint about the domain? (Database, HTTP, parsing, etc.)
• Does it avoid actively misleading people about what it does?
• Could someone plausibly guess the category from the name alone?

That’s it. MongoDB clears this bar. PostgreSQL clears it. “Marmot” for a SQLite replicator does not. “Isso” for a commenting system does not. “Viper” for configuration management does not.

The question isn’t “are descriptive names perfect?” They’re not. The question is: “are they better than random words?” And the answer is obviously yes.

Every defense of arbitrary naming boils down to: “descriptive naming has edge cases and costs.” True. But those costs are one-time (renaming, choosing carefully) or constrained (scope can’t silently expand). Random naming has perpetual costs paid by everyone who encounters the tool, forever.