Programmers and software developers lost the plot on naming their tools

> “But memorable names help with marketing!”

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

I agree. I've worked in places that discourage "cute" names and the result is often things like having to decide between using CoreMainHttp and MainHttpCore. Or worse, two things with exactly the same name, but two different APIs, with projects sometimes taking both as a dependency at the same time. Or even obsolete parts of the org chart encoded into dependency names, like "DataOrgUtils" when the "Data Org" stopped existing several reorgs ago, when our current VP was an intern and nobody else even worked here.

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.