Re: Names are not descriptions; descriptions are not names

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 11 May 2023 23:01:24 -0500
> From: Adam Porter <adam@alphapapa.net>
> 
> There is no better way to doom software to obscurity than to give it a
> description as its name.  Names are not descriptions; descriptions are
> not names.

No one said names should be descriptions.  The request was to make the
name of a package include some hint on what the package does and where
it is applicable.  Just a hint, nothing more.

> It's doubly a problem for a package that has similar functionality to
> existing packages.  For example, with regard to "devil", the package
> recently proposed by Susam Pal, various alternative, ostensibly
> descriptive names have been proposed, like "key-transl",
> "no-modifier-mode", "prefixless-mode", "implicit-ctrl-mode", and
> "comma->control-mode".  If one of those names were used, how would a
> user distinguish such a package from other packages that do similar
> things, such as viper, evil, god-mode, meow, boon, and the numerous
> other similar ones that are out there?

Again, there's no requirement to allow users distinguishing between
similar packages just by looking at the name.  That can only be done
by reading the package's description.

IOW, the name should allow some kind of initial filtering: if I'm not
interested in key translation, I don't need to look further at a
package named key-transl.  It's the same first-order filtering we
apply to email by just looking at the Subject.  Nothing more, nothing
less.  We advise people to use descriptive enough Subject in their
email messages so that interested people will take notice; sending a
message whose Subject says "42" will only catch attention of a group
of people who have read the book and remember the significance of the
number, but not others.  Likewise with package names.

> 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 (who
> hasn't experienced this already: installing a package, configuring it,
> and then forgetting about it, finally being unable to remember the
> name of the package that does the thing that one suddenly needs the
> functionality of again, having to search ELPA or MELPA for such a
> tool, and then discovering that one already has it--well, maybe it's
> just me).

How many package names can a user remember? 10? 20?

There are many hundreds of packages out there.  No one can possibly
memorize them, even if each one of them had a catchy name.  It is
impractical to expect that, and therefore requesting each package to
have a catchy name is not very important: its goal cannot be reached
in practice anyway, so why request that?

> As an Elisp package author, I can vouch that part of the joy of
> programming is creation, and part of the joy of creation is in naming
> one's creations.  Let us not steal this joy from the authors who
> generously contribute their time and work to the public good that is
> Emacs and ELPA.

I see your point, but please also see ours.  We are not looking at
this via a loophole of an author of several packages, we are looking
at this from the wider POV of managing Emacs as a project.  From our
POV, having packages whose names don't even hint on their purpose is a
significant disadvantage.  So we respectfully request package authors
to cooperate by coming up with names which don't have this downside.
If package authors can come up with smart names that also hint on
their use areas, the joy you mention can be preserved, but without the
downsides.