A Simple Matter of Programming

It’s said that naming things is one of the more difficult aspects of programming. Lately, it hasn’t been as much of a problem for me as it used to be. Ruby doesn’t make you have as many classes to name as Java does. And when you really get to know Ruby, you figure out that local variables are basically useless too, which makes for even less things to name. But there’s still the matter of has_many :through models in Rails, which almost always feel contrived.

Suppose we were to invent a language for naming things. You could start with more or less English vocabulary, I suppose, but you would change things.

First of all, you would want it to be highly inflected in useful sorts of ways. Temporal inflection (past tense, etc) would have to be replaced with something more useful to computer time, with an eye toward the conceptual complexity of thread management. Plurality would stay mostly the same, but you would add another inflection for collections of things (singular words for pluralities, which are ad hoc in English).

Also, I tend to care a lot about how things lay out spatially. I like my code to line up in two dimensions. Sometimes I even make pictures and diagrams in my code (in a very abstract sense). The English language has a bit of serendipity here:

dx = [other.right - left, other.left - right].map(&:abs).min
dy = [other.bottom - top, other.top - bottom].map(&:abs).min

On the other hand, you have the absurd imbalance of the ultimate dichotomy, true and false. Our hypothetical language, then, would insist that all words in a semantic set have the same number of letters, so that things will line up.

But I think the greatest significance of a new language would be to remove the inhibition to making up words. There are thousands of concepts that don’t have good names even outside of programming (see The Meaning of Liff). The original intent, as I understand it, of Christopher Alexander’s design patterns was not to put together a toolbox of design techniques, but to put together a pattern language for discussing and understanding design, as it is done by designers.

I tried to use design patterns in Java, and they never really felt right. I think most of the Java patterns, converted to Ruby, end up being a block. Just a block. Consequently, my attitude toward design patterns has been that they were standard hacks around limitations of the language. You don’t hear a lot about patterns in Ruby land.

I think we lost something when patterns became prescriptive rather than descriptive. I would expect that there are some very abstract practices in Ruby that would be worth naming, if we thought about it. It’s much easier to codify things in Ruby than in Java, so it may be that certain libraries are actually living design patterns. But there’s plenty of difference between really good Ruby code and really bad Ruby code, and I think we could describe the difference, and it’s usually more than just a missing library.

A better language helps you to think better thoughts. At some point the programming language itself is no longer the bottleneck, and innovation has to happen elsewhere. I’m not really sure what the right approach is here—I’d hate to decrease the accessibility of programming. But I’m proud to be in the only field I know of that has this problem. We are the only sons of Adam who carry on the tradition of the naming of the beasts.