Re: Names are not descriptions; descriptions are not names

[Jim Porter <jporterbugs@gmail.com>]

On 5/11/2023 9:01 PM, Adam Porter wrote:
> And by burdening the name with a responsibility it cannot bear, the
> name suffers, the package suffers, and ultimately, the user suffers.
> The "descriptive" name is not memorable; the user likely forgets what
> it's called a few weeks after installing and configuring it...

I strongly agree. While some projects have bad names (as an illustrative 
example, CHEATING: "obsCure and awkHward usE of lettArs Trying to spell 
somethING"[1]), a name's primary purpose is to be a memorable way of 
referring back to something you already know about. That means it should 
be easy to see how the name relates in some way to its purpose, but it 
doesn't need to be immediately apparent what it does just by looking at 
the name.

Probably my favorite project name in existence is "pacman", Arch's 
package manager. If I didn't know about it and you asked me to guess 
what it did, I'm sure I'd say, "It lets you play Pac-man," but once I 
know it's a package manager, the name makes perfect sense and I can 
easily remember it.

When I'm looking for a package on ELPA (or built into Emacs) to do XYZ, 
I don't generally consult the name at all, and instead read/search the 
description or the manual. About the only time I look at the name is if 
I'm searching for a major mode of a programming language, which is 
almost always "lang-mode".

That's not to say there are no issues whatsoever with naming: if a name 
is really obscure or particularly rude, those are good times to suggest 
a rename. For "devil" in particular, I think it's a pretty reasonable 
choice, since just by looking at the name I guessed that it was 
something in the same overall genre as evil. Maybe there's a better name 
out there, but I think it's still better than any suggested alternative.

However, I think there's potentially an even bigger issue: package 
discoverability as a whole. I imagine we all hope that Emacs will 
continue to get many new users, and they likely won't be able to guess 
anything about a name like "devil". We should do our best to make sure 
packages like that are easy to discover if you use some common search terms.

This might also include making it easier for novices to learn *how* to 
perform good searches. I'm not sure exactly what this would entail (it's 
hard to unlearn what you already know), but I am sure that it would be 
valuable. Emacs gives you an awful lot of tools to be able to learn on 
your own and dig deeper into customizing/extending it, but it can be 
hard to get started: it took me more than a decade to move past the 
stage of "copy-pasting Elisp code from other people's configs".

- Jim Porter (no relation)

[1] https://www.bmj.com/content/349/bmj.g7092