* Names are not descriptions; descriptions are not names @ 2023-05-12 4:01 Adam Porter 2023-05-12 4:47 ` Jim Porter ` (3 more replies) 0 siblings, 4 replies; 13+ messages in thread From: Adam Porter @ 2023-05-12 4:01 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter @ 2023-05-12 4:47 ` Jim Porter 2023-05-12 20:02 ` Dr. Arne Babenhauserheide 2023-05-12 6:04 ` Po Lu ` (2 subsequent siblings) 3 siblings, 1 reply; 13+ messages in thread From: Jim Porter @ 2023-05-12 4:47 UTC (permalink / raw) To: Adam Porter, emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 4:47 ` Jim Porter @ 2023-05-12 20:02 ` Dr. Arne Babenhauserheide 0 siblings, 0 replies; 13+ messages in thread From: Dr. Arne Babenhauserheide @ 2023-05-12 20:02 UTC (permalink / raw) To: Jim Porter; +Cc: Adam Porter, emacs-devel [-- Attachment #1: Type: text/plain, Size: 3073 bytes --] Jim Porter <jporterbugs@gmail.com> writes: > 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... > > 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. That name is descriptive, but unique enough to latch onto memory. And you can discover it if you remember "something about packages", so you type pac<TAB><TAB> on the shell. > 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". I fulltext-search the package listing. M-x package-list-packages C-s <whatever> C-s (repeat) I don’t have time to read all the one-line descriptions. And I like having somewhat descriptive names. Try to remember how to open a PDF on the command-line. Gnome: evince — it took me months to remember that. KDE: kpdf. It once was. Now it’s okular. That’s still somewhat evocative of seeing something, so better than evince, but I preferred kpdf. And for kwrite it is obvious what it does. Same for gedit — I never forgot gedit, even though I use it rarely. If I’m not yet fully awake in the morning when I get up to make the lunchboxes for the kids, I can still remember gedit. I can also remember icecat, because that’s like firefox. And lftp still works. But audacity I have to search when I didn’t use it for a while. Same for clementine and even worse "whatever is the default image viewer" (no, I really don’t know; doesn’t help that the name is not in the program listing ...) — and don’t ask me to remember xdg-open or M-x browse-url-xdg-open — it always takes me several tries to remember the correct command, and that’s with ido-completion in the commands. Or worse: the advanced video-editor that’s not kdenlive. Though naming with something else than the most obvious description becomes important once there is more than one package for the same task. I often use amx to search for something: M-x org-<something I want to do> And all in all there’s an old truth: naming is hard. While a fixed rule like "name not description not name" can help to avoid the trap of thinking that the name *must* be a description, I think it is too simplistic to steer the process of finding a good name. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter 2023-05-12 4:47 ` Jim Porter @ 2023-05-12 6:04 ` Po Lu 2023-05-12 7:46 ` Adam Porter 2023-05-12 17:52 ` chad 2023-05-12 6:42 ` Philip Kaludercic 2023-05-12 7:37 ` Eli Zaretskii 3 siblings, 2 replies; 13+ messages in thread From: Po Lu @ 2023-05-12 6:04 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-devel Adam Porter <adam@alphapapa.net> writes: > Subject: Names are not descriptions; descriptions are not names They should be. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 6:04 ` Po Lu @ 2023-05-12 7:46 ` Adam Porter 2023-05-12 13:31 ` [External] : " Drew Adams 2023-05-12 13:58 ` Po Lu 2023-05-12 17:52 ` chad 1 sibling, 2 replies; 13+ messages in thread From: Adam Porter @ 2023-05-12 7:46 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel On 5/12/23 01:04, Po Lu wrote: > Adam Porter <adam@alphapapa.net> writes: > >> Subject: Names are not descriptions; descriptions are not names > > They should be. Then shouldn't we rename Emacs? ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [External] : Re: Names are not descriptions; descriptions are not names 2023-05-12 7:46 ` Adam Porter @ 2023-05-12 13:31 ` Drew Adams 2023-05-12 13:58 ` Po Lu 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2023-05-12 13:31 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-devel > > Atom Porter writes: > > > >> Names are not descriptions; descriptions are not names > > They should be. > > Then shouldn't we rename Emacs? Atom's already been named (and deprecated). ;-) Oh, the treachery of names! This is not a name. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 7:46 ` Adam Porter 2023-05-12 13:31 ` [External] : " Drew Adams @ 2023-05-12 13:58 ` Po Lu 2023-05-12 19:10 ` Dmitry Gutov 1 sibling, 1 reply; 13+ messages in thread From: Po Lu @ 2023-05-12 13:58 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-devel Adam Porter <adam@alphapapa.net> writes: > Then shouldn't we rename Emacs? Its name is a historical accident, but if it were possible, then yes. Unfortunately, `Editor' is already taken. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 13:58 ` Po Lu @ 2023-05-12 19:10 ` Dmitry Gutov 0 siblings, 0 replies; 13+ messages in thread From: Dmitry Gutov @ 2023-05-12 19:10 UTC (permalink / raw) To: Po Lu, Adam Porter; +Cc: emacs-devel On 12/05/2023 16:58, Po Lu wrote: > Adam Porter<adam@alphapapa.net> writes: > >> Then shouldn't we rename Emacs? > Its name is a historical accident, but if it were possible, then yes. > Unfortunately, `Editor' is already taken. Editor#2. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 6:04 ` Po Lu 2023-05-12 7:46 ` Adam Porter @ 2023-05-12 17:52 ` chad 2023-05-12 19:11 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: chad @ 2023-05-12 17:52 UTC (permalink / raw) To: Po Lu; +Cc: Adam Porter, emacs-devel [-- Attachment #1: Type: text/plain, Size: 280 bytes --] On Fri, May 12, 2023 at 2:06 AM Po Lu <luangruo@yahoo.com> wrote: > Adam Porter <adam@alphapapa.net> writes: > > > Subject: Names are not descriptions; descriptions are not names > > They should be. > Bertrand Russel would _emphatically_ disagree with you. ~Chad [-- Attachment #2: Type: text/html, Size: 701 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 17:52 ` chad @ 2023-05-12 19:11 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2023-05-12 19:11 UTC (permalink / raw) To: chad; +Cc: luangruo, adam, emacs-devel > From: chad <yandros@gmail.com> > Date: Fri, 12 May 2023 13:52:27 -0400 > Cc: Adam Porter <adam@alphapapa.net>, emacs-devel <emacs-devel@gnu.org> > > On Fri, May 12, 2023 at 2:06 AM Po Lu <luangruo@yahoo.com> wrote: > > Adam Porter <adam@alphapapa.net> writes: > > > Subject: Names are not descriptions; descriptions are not names > > They should be. > > Bertrand Russel would _emphatically_ disagree with you. Bertrand Russel cannot post here, as he is not subscribed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter 2023-05-12 4:47 ` Jim Porter 2023-05-12 6:04 ` Po Lu @ 2023-05-12 6:42 ` Philip Kaludercic 2023-05-12 7:37 ` Eli Zaretskii 3 siblings, 0 replies; 13+ messages in thread From: Philip Kaludercic @ 2023-05-12 6:42 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-devel Adam Porter <adam@alphapapa.net> writes: > 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. I agree, but this is a strawman. As you are referring to the thread about "devil-mode" from earlier this week, I'd argue the position was not to find a name that perfectly describes the package, but to find a name that is remotely related to the functionality of the package. > 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"? I think that org-sticky-header is a fine name. I think that "gecko-mode" would be a bad name, even though they are also sticky, because understanding why the package was given the name is far easier than inferring the scope of the functionality from the name. > 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.) This is an argument against long names. The situation I usually have in mind is when people cannot remember a name, because the name is arbitrary. There is a reason why GNOME allows for both application-specific names and generic names. I regularly use the graphical file manager, but don't ask me what the proper name of the application is. Something like "nemo" or "nautical"? > 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." The issue here is that you are using an indefinite article. I think Hey, I found a useful package called "key-translate". You should try it. is a lot clearer. > "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? There is a counter-tendency to what I mentioned above, and that is that over time popular names become descriptive in and of itself. Take "grep", while we might know what it means and where the name came from, most people have to memorise the name. But this ends up being acceptable, since the term is so widespread. That being said, I always remember how when learning how to use a shell, I initially refused to use "grep", and instead looking for a program like "filter" or "search", that would have been consistent with the other commands like "mv", "cp", "cd", etc. "Grep" sounded like some non-standard utility that I would have to install from somewhere. > 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. I think of my father, who despite having started using Unix system in the 1990's and understands how everything works, just cannot remember names like "apt" when software has to be upgraded. That means I have to do it instead. One mans joke is another mans arbitrary, opaque identifier that has to be memorised. > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter ` (2 preceding siblings ...) 2023-05-12 6:42 ` Philip Kaludercic @ 2023-05-12 7:37 ` Eli Zaretskii 2023-05-12 16:33 ` Jim Porter 3 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2023-05-12 7:37 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Names are not descriptions; descriptions are not names 2023-05-12 7:37 ` Eli Zaretskii @ 2023-05-12 16:33 ` Jim Porter 0 siblings, 0 replies; 13+ messages in thread From: Jim Porter @ 2023-05-12 16:33 UTC (permalink / raw) To: Eli Zaretskii, Adam Porter; +Cc: emacs-devel On 5/12/2023 12:37 AM, Eli Zaretskii wrote: > 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. Looking at the list of packages in GNU ELPA, almost all of them have a description well within the limits of what we'd expect from an email Subject. To use your example of "42", while that alone would be cryptic, a Subject like "42: The answer to life, the universe, and everything" would be ok, I think. That being said, are there places we can make package descriptions more visible? Both "M-x list-packages" and the ELPA package list on the web show the descriptions prominently, so I find them both to be very easy to find packages, even if they have cryptic names. However, there may be further improvements we should make in this area. Packages can have keywords, so improving those might help, or maybe we could add metadata for broad package categories (e.g. "theme", "key bindings", "major mode", etc)... Still, there's room for a light touch with improving package names (especially if we let the actual package *identifier* be a slight variation on the name). For example, the Devil package could otherwise stay the same, but we could give it a package identifier of "devil-keys". The functions and commands would still just be "devil-FOO", and the documentation could still say "devil" instead of "devil-keys" (except when talking about how to install the package, of course). Would that be a reasonable compromise for cases like this? ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-05-12 20:02 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-05-12 4:01 Names are not descriptions; descriptions are not names Adam Porter 2023-05-12 4:47 ` Jim Porter 2023-05-12 20:02 ` Dr. Arne Babenhauserheide 2023-05-12 6:04 ` Po Lu 2023-05-12 7:46 ` Adam Porter 2023-05-12 13:31 ` [External] : " Drew Adams 2023-05-12 13:58 ` Po Lu 2023-05-12 19:10 ` Dmitry Gutov 2023-05-12 17:52 ` chad 2023-05-12 19:11 ` Eli Zaretskii 2023-05-12 6:42 ` Philip Kaludercic 2023-05-12 7:37 ` Eli Zaretskii 2023-05-12 16:33 ` Jim Porter
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.