Names are not descriptions; descriptions are not names

[Adam Porter]

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.

Rarely, for a simple enough package, a short description may be a
reasonable choice for a name.  For example, "org-sticky-header"
conveys that it's for Org mode and that it provides a sticky header.
Assuming, that is, that the user knows what a "sticky header"
is--otherwise, what should it be called?
"org-header-line-that-shows-the-outline-path-at-the-top-of-the-window"?
Now imagine one user trying to share that package with another user:

    Alice: "Hey, I found a package that I think you'll find useful:
    org-header-line-that-shows-the-outline-path-at-the-top-of-the-window."

    Bob: "Oh, that does sound useful.  What's it called?"

    Alice: "I just told you."

    Bob: "Yes, but what's the name of the package?"

    Alice: "That's it."

    Bob: "No, I need the name so I can install it and try it."

    Alice: "I just told you the name."

    Bob: "No, you told me what it does."

    Alice: "Yes, but that's the name."

(With apologies to Abbott and Costello.)

I'm not merely joking, I'm also serious.  This is a real problem.

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?  (Note that, although I use
none of those packages, I remember them because of their distinctive
names; had they descriptions as names, I would not remember them, nor
would I be able to easily find them again.)  We're faced with the
same problem:

    "Hey, I found a useful key-translate package.  You should try it."

    "Oh, I already use evil-mode."

    "No, not that one.  This one."

    "Well, which one is it?  There are a bunch of those, like viper,
    evil, god-mode, meow, boon..."

    "key-translate."

    "Yes, I understand that it does that, but what is it called?"

    "The name itself is key-translate."

And that brings us back to the heart of the issue: "Oh, ok.  So how is
it different than viper, evil, god-mode, meow, or boon?"  That is, the
user must read the description (or even the whole readme) to
understand what the package does.  The name is not enough; the name is
never enough.

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

Of course, it's a laudable goal to reduce confusion for users.  Yet,
although Ed is the standard editor, do we not use Emacs?  What do
potential users say about that?  "Didn't Apple stop making those a
long time ago?"  Are they not confused?  Should we rename Emacs to
gnu-lisp-machine-with-built-in-editor?  Would we not shorten such a
name to GLiMBiE?  And would such a name be descriptive?

I'd like to share a link to a short essay published earlier this year
that reminded me of these threads on emacs-devel:
https://ntietz.com/blog/name-your-projects-cutesy-things/ Although
it's mainly about service names rather than software packages, its
points are relevant here:

    And then the cherry on top, the final nail in the coffin of
    descriptive names: They're just too hard to say and remember, and
    they're no fun. I don't want my services or projects to sound like
    a law firm ("Ingest, Processing, & Storage LLP"). A descriptive
    name will be wordy, or boring, or both. It won't be memorable, and
    it won't be fun. On the other hand, something that's cute will be
    far more memorable and much easier to say.

    The world is boring enough as is. Let's add more whimsy and
    cuteness through our service and project names.

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'll close with these words from Alan J. Perlis, quoted in Abelson's
and Sussmans' classic, /Structure and Interpretation of Computer
Programs/:

    I think that it's extraordinarily important that we in computer
    science keep fun in computing. When it started out, it was an
    awful lot of fun. Of course, the paying customers got shafted
    every now and then, and after a while we began to take their
    complaints seriously. We began to feel as if we really were
    responsible for the successful, error-free perfect use of these
    machines. I don't think we are. I think we're responsible for
    stretching them, setting them off in new directions, and keeping
    fun in the house. I hope the field of computer science never loses
    its sense of fun. Above all, I hope we don't become
    missionaries. Don't feel as if you're Bible salesmen. The world
    has too many of those already. What you know about computing other
    people will learn. Don't feel as if the key to successful
    computing is only in your hands. What's in your hands, I think and
    hope, is intelligence: the ability to see the machine as more than
    when you were first led up to it, that you can make it more.