Programmers and software developers lost the plot on naming their tools

There is actually a good reason not mentioned, not to name tools by their purpose:

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

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

A good reason to use arbitrary code names before assigning a more helpful name upon release of something deemed to now be generally usable, beyond developers with caveats.

Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.

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

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

I'd rather have a name that works as an Id.

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

> We shouldn't be optimizing to avoid renaming.

> 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?

I like this approach. Use a cute, fun, memorable name internally for stuff getting off the ground. Once it becomes user facing, the internal name becomes a fun note on Wikipedia and the world sees the actual calculated name.