1. 23
  1.  

  2. 14

    The chapter on naming things from Elements of Clojure does a great job digging into how to think about naming things. I strongly recommend junior devs read it when I discuss naming practices with them.

    1. 4

      That remains one of the most cogent discussions of naming I’ve ever read. Applies way beyond Clojure!

      1. 1

        I would like to add that, no other profession, I think, creates so many new names for so many abstract things.

        We create names on a daily basis, and it’s a skill/subject glossed over by schools and everyone, while names are a central form of communication we developers use and consume every moment. It’s wild that naming doesn’t get enough attention and we don’t even have a book dedicated to it, as I think we should.

      2. 4

        After reading, I still think “naming things” is a pretty clear name for naming things.

        1. 3

          I get the feeling that this is a really good way to describe to crowds of non-computer people what it is I do all day and why it’s so hard. Sure, there are many other aspects of the job, but this is one that’s not talked about a lot in the mainstream, yet should be easy enough to understand. And the ideas of hair-splitting generalise well to some other aspects of the craft.

          1. 2

            With apologies to Hilel, I know he’s had a bad week, I don’t think he knows what he’s talking about here. He’s trying to domain model naming. That’s like trying to pee your way out of the ocean: it may feel good at the time, but the long-term benefits are dubious at best.

            He ends with this, which seems appropriate. “…There’s probably a lot more ways of “naming things” I couldn’t think of. They’re probably all hard, too. Naming things is hard because it could mean a bunch of different hard things. But you don’t realize that from just “naming things”. I can’t think of a better name for “naming things”, though. Naming things is hard….”

            By way of rebuttal, I will be overly brief:

            Anytime a word or gesture comes out of your mouth, as a sentient creature you are in the process of creating or modifying language. Language is mostly a performative art, but over time we’ve realized that we can use formal systems to reason in a way that is language free. Gravity doesn’t care what you call your terms. It works anyway. So the universe is completely language-free.

            Of course we can’t deal with the universe without going through our little performative social dance we call language, so there we are: we are forced to use jello to build a cathedral. It’s amazing the damned thing works at all (long discussion here about how and why it works). As coders we come in on the tail end of this, trying to create and modify formal systems, sticking names and such on the various things we do and create (domain models, variable names, and so forth). He does a reasonably good first pass separating all of those out. The problem, as he begins to realize this towards the end, is that he’s headed down the road of a universal ontology, a master domain model to rule them all. Good luck with that. If you succeed we humans couldn’t use it, but the good news is that if you don’t succeed you’re in good company. It’s what we all do.

            Worth reading.

            1. 4

              But there are at least three philosophies which use nomenclature to talk specifically about the form of names, and these philosophies are still interesting even when language and encoding are arbitrary.

              First, in category theory, assume that we’re in a category with a terminal object and all exponential objects (it would be Cartesian closed). Given an arrow f : A → B, the name of the arrow is another arrow [f] : 1 -> B**A which is isomorphic to f. If one has the name of an arrow, then they can invoke the original arrow.

              Second, in object-capability theory, any delegation of authority creates a capability. A capability is a name for the delegated authority. Objects can hold capabilities, and themselves can delegate the authority to be called by other objects. If one has a capability to an object, then they can invoke the object.

              Third, in certain various religious practices, a true name allows for some sort of direct control or summoning of people. If one has the true name of a person, then they can invoke the person.

            2. 1

              Code Complete had a good section on naming things. I particularly liked how it emphasized where and how two names differ (aThing/bThing vs thingA/thingB vs someAThing/someBThing - the first pair is the quickest to disambiguate).

              1. 1

                I find that naming things is hard when I don’t (yet) understand what I’m building - but easy when I do.

                Does this mean that domain understanding is hard and the difficulty with naming things is a side effect?

                1. 2

                  That’s one way to interpret the evidence. Another is that the difficulty of naming things doesn’t change, only your perception of it. In other words, when you know the domain well, you’re good at fooling yourself that you’ve come up with great names, when in fact they may be no better than before.

                  Not suggesting anything either way, just dropping in with a reminder of how not receiving a signal is not evidence of there being no signal.