1. 8
  1.  

  2. 4

    If we accept the premise that there is a lot of value in the uniform morphology, Esperanto could be an option suited for ASCII (in the orthography with «x» instead of diacritics, of course). Then there is also Toki Pona. Many people prefer just to combine enough separate English words to get the point across.

    But I think there is another linguistical problem to consider: naming things in programming is hard because programming is an activity where minor semantic distinctions often matter. Maybe a uniform morphology would help by reducing verbosity and allowing to put more meaningful roots in the name of a given length; but anything general enough to be universally useful would have to be vague enough to be subtly misleaing in the specific cases anyway.

    The problem is not just to remember the words — «reading with a dictionary» is a skill older than programming. The problem is that too much details are needed for defining even a single word.

    1. 2

      Maybe. But you can also look at it from the other side: If morphology is standardized, people, being pattern-loving animals, would try to use the constructs consistently, i.e. try would try to make relationship between “parse” and “parser” be similar to relationship between “scan” and “scanner”. Eventually, the constructs could come to represent something like “design patterns”, something that you can assume to work in some specific way.

      1. 1

        Well, the design pattern called Factory definitely has its own «-Factory» suffix. And predicates often get an affix of one or two characters («is», «-p», «?»). And Hungarian notation was used.

        My fear is that humans are actually too good at pattern matching, so if all you have is «-er», you will get «parser» regardless of whether it tries to parse a prefix or requires a whole-string match.

        Do you hope that using a spoken language with a lot of morphological modifiers as a base will affect the culture to create enough new modifiers for smaller patterns? I mean enough to avoid combining any dangerous-to-combine notions. I find this plausible, but not guaranteed; I guess naming things in Esperanto could be a way to try.

        1. 2

          I don’t know really, but it might be worth a try. At least when a programmer talks to another programmer in person, they use natural language to get through the idea. This is often (at least in my experience) superior to just reading the code. So, maybe, if we were able to take a bit of this person-to-person communication in convey it via the code, it would help to some extent.

          1. 1

            Well, in person-to-person communication there is not only different naming (I would be surprised if some structured morphology not used in the variable naming would arise), there are different protocols for manging the level of details. You can get an overview that is not just «N levels deep in the call tree». Sometimes abstractions are also intentionally lossy, which you are usually not allowed to do in code.

            Some things depend on feedback, there is some research into allowing zoom in/zoom out for abstraction levels, but improving state of art in the area of zooming out the programming abstractions would definitely be valuable.

            1. 1

              Yep. That’s why I said “a bit” :)

              1. 1

                My point was also that we currently have more tools for lexical part than for grammatical part. Is morphology still where the best return on effort is? (I honestly do not know)

                1. 1

                  I don’t think this would help with the tooling. However, it would decrease the amount of lexical baggage which in turn could help with, say, keeping the learning curve flat, or, maybe, returning to old code years later, remembering just the core concepts and being able to get up to speed immediately.

                  1. 1

                    I meant tools in a wider sense including conceptual tools.

                    Intuitively, a flat learning curve is not something you can achieve in an experiment (the morphology has to be learnt first). So this part is hard to know (getting data from Esperanto taking off only for code identifiers and comments sounds a bit optimistic).

                    It would be of course interesting if there were some subset that you could try with moderate effort and then tell a success story.

    2. 1

      This blog post is a little unclear to me, it should probably be refactored. There some issues I noticed on a first pass:

      1. A numbered list is used when it should be structured as paragraphs, possibly with section headers.
      2. No hyphen should be included between internally and used in paragraph 6.
      3. I don’t understand how word declensions in Arabic differ from word declensions in English.
      1. 1

        Naming is about communicating from one human to another with an extremely low amount of information (function name) with a high amount of meaning (that function’s behavior).

        Really wish all this code cross-refrence tooling focused on showing documentation & linking it, not code. Texinfo is mediocre, but supports the type of indexing that is useful.

        1. 2

          Agreed. I have compared this to the saying that “sometimes the only way to escape the fire is to run through it”.

          I don’t mean this in a practical sense for doing today in your source code, but as a philosophical concept. It’s better to name something “oldPanda” than “findLastUserUnpaidInvoiceSomethingSomething”.

          In the first instance you just assign a name, a symbol, to a concept. You are not fighting to pack lots of information into a tiny space. Because the symbol is meaningless it can precisely mean what it is representing.

          In the second instance you make an attempt at packing information into somewhere that simply does not fit. Now this incomplete and inaccurate name will become one of your worst enemies for years to come.

          The relation to that saying at the top is that just like running through fire having obscure symbols and names is something we want to naturally avoid so we try to cram meaning into variable names which is perhaps the “obvious” solution like running away from a fire, but it’s not necessary always the best.

        2. 1

          Naming things is so hard. Even within the same team people use different names for things. One of the hardest things when you’re programming is writing code with the goal of it being easy to use for the rest of your team.