1. 8

  2. 7

    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?

    Not to take away from the author’s point, but GNU LiMBiE is actuały a pretty cool name imo.

    1. 5

      Reminded me of this: Long Names Are Long

      1. 3

        Sounds like a false dichotomy - a name can be both descriptive and short (KeePass, LibreOffice, Document Scanner), or even descriptive and cute (Files, xAutoClick, Cheese). Names which give no hint whatsoever what the thing does are bad. It’s exasperating rather than cute. Having to read a zillion descriptions to understand what should be scannable is the worst.

        Thankfully, others at GNU don’t agree with OP: Files used to be called Nautilus, and Passwords and Keys used to be called Seahorse. Imagine looking at the old names and trying to judge what they do, or whether they’re the main application for their use case or just another copy-cat.

        On a less serious note, some naming suggestions for GNU EMACS:

        • GNU’s Not (Just) EMACS (GNE, pronounced “genie”)
        • Hardcore Text Editor (HaTE)
        • You Ain’t Gonna Remember All The Shortcuts (YAGRATS)
        1. 0

          I find your nick and mine quite ok, despite being not descriptive. And they are names, right? Maybe names isn’t what you want for packages but rather short descriptions.

          I find names being human handleable, practical, good-enough, convenient identifiers. Being descriptive is optional and sometimes whimsy.

          And about judging - looking at names and not bothering about the thing maybe judging a book by it’s cover.

          1. 2

            This discussion is about product names, not personal names.

        2. 3

          So, why do we have names? Because we store packages in indices with names for keys. Maybe we shouldn’t have package indices.

          Maybe we shouldn’t have packages; this is a very tough concept but worth pondering. Quoting the question in its entirety:

          Suppose that a programming language has modules, but does not have a notion of packages or other collections of modules. Which software engineering tasks are expensive or impossible without packages?

          1. 2

            Sorry, I’m getting a 404 on the one you linked to.

            1. 2

              I quoted it in full, so you’re not missing anything. I’ve also posted a new question which asks in more detail:

              Suppose that a programming language admits ML-style modules, but its ecosystem does not have ML-style packages. Which software engineering tasks – if any – are expensive or impossible without packages?