Programmers and software developers lost the plot on naming their tools

Technically it is "combine". Originally it was known as a "combined harvester-thresher", which is maybe what you're thinking of, but that was soon shortened to "combine" and it has stuck ever since.

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

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.

> Our field deserves better than a zoo of random nouns masquerading as professional nomenclature. Clarity isn’t boring, it’s respect for your users’ time and cognitive resources.

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

I believe strongly in this counterargument:

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)

End of the day you know what it means or you don't. I agree it's helpful when a name is descriptive, but there's no helping the fact that you're going to have to learn the names of things that aren't obvious. Purely utilitarian names would constantly collide.

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.