From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Names are not descriptions; descriptions are not names Date: Fri, 12 May 2023 06:42:49 +0000 Message-ID: <87ednmxd7a.fsf@posteo.net> References: <3b4a24a3-2d12-16d3-d905-7794ed4269b1@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33906"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 12 08:43:34 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pxMV2-0008fA-V0 for ged-emacs-devel@m.gmane-mx.org; Fri, 12 May 2023 08:43:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxMUR-0002Ge-RY; Fri, 12 May 2023 02:42:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxMUR-0002GW-3I for emacs-devel@gnu.org; Fri, 12 May 2023 02:42:55 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxMUO-0006LU-CN for emacs-devel@gnu.org; Fri, 12 May 2023 02:42:54 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4F53E2401AC for ; Fri, 12 May 2023 08:42:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1683873770; bh=lUnt77oxRsyNEuRb/WItIY+EdcJ8C/xU25CKj9QG6ho=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=A/LizsKbjE2Fc2I9c+UbnDoVIq+RNYJxPXa4NQOed1QF+eZeogUbI6hAVcf9k9Rqt 2BHoUESN6ukVTuCNYfwRvYnPU4zDYOaaLBFmJnnRDan4ylwm5Dk0gCm+CyETE+dTG2 aiK2+W3CikdA41Z1apUtOHpxx5UBJns8iEivwW7nE2W7ZfiTZoEkzTNWnogMpLwWUu 8T6JMD5mQG0xJTKbi+Lq+HQQAUvZDE1CcSK9z70NMcUZK1H06pkNDUbFq/pYqg0u4/ veL0/YKEGFBkawmMxG+GYy49LmBRhJ0ftdH3wPE/7BOnb8GSjQxTdFM8ZCEZ3wQmV+ j/HJYkMkgDd6w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QHfMs5Wmzz6tm4; Fri, 12 May 2023 08:42:49 +0200 (CEST) In-Reply-To: <3b4a24a3-2d12-16d3-d905-7794ed4269b1@alphapapa.net> (Adam Porter's message of "Thu, 11 May 2023 23:01:24 -0500") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306074 Archived-At: Adam Porter 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.