←back to thread

311 points todsacerdoti | 1 comments | | HN request time: 0s | source
Show context
marifjeren ◴[] No.46235167[source]
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.

replies(3): >>46235330 #>>46235354 #>>46235368 #
lr0 ◴[] No.46235330[source]
"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).
replies(1): >>46235470 #
dietr1ch ◴[] No.46235470[source]
> 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.

replies(1): >>46235633 #
lr0 ◴[] No.46235633[source]
> 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.

replies(3): >>46235673 #>>46237799 #>>46239246 #
1. queenkjuul ◴[] No.46237799{3}[source]
> 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?