Spoken Languages, Blub, and Convenience

language-design (4), thoughts (9)

Many programmers have read Paul Graham's essay Beating the Averages which develops a theory of programming language hierarchies. A programmer used to a programming language that doesn't provide certain functionality has trouble imaging how that functionality could be useful. After all, they've gotten along so far without the feature, so it can't be that important, right?

In Graham's words:

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

One thing that I don't think has received enough consideration is that this reasoning applies in an interesting way to human languages as well. Different spoken language are specialized towards certain types of communication. English is a language obsessed with time, with a medley of future, past, present, perfect, and progressive tenses. But English isn't as precise at expressing formality as Spanish or French are, both of which have incorporated formality into verb conjugation. Japanese on the other hand, has codified formal speech more precisely than most Western languages1,

Japanese, further differentiating itself from English, doesn't have a future tense: saying "I will go to school" and "I go to school" are expressed in the exact same way. However, Japanese is adept at expressing emotional nuance, and has a few tricks up its sleeves to help talking about temporal events (words like ototoi, asatte, saraisyuu--which respectively mean "the day before yesterday", "the day after tomorrow", and "the week after next"--are really nice to have, and I wish English had equivalents).

Stepping back a bit, lets continue the comparison at work with Graham's argument about blub languages. Specifically, do we think we could make a case for a hierarchy of power among spoken languages? Its a difficult thought exercise to begin, in large part because each language has its own specialized domain (formality, time, emotional nuance, etc), and thus our hierarchy of power would become entirely dependent upon our definition of power. We can easily enough argue English is more powerful than Japanese--if we're talking about time--but changing the definition of power we can quickly enough reverse that statement.

However, I think we can suggest that a fairly clear power hierarchy exists between modern Italian and Latin. Italian greatly resembles Latin, except it has lost many of the tenses and complexities of Latin. Just as Lisp's tragic history of losing to its less powerful successors to its ideas, Latin's structure and grammatical depth have given way to its less potent children (the Romance languages).

Why do more powerful solutions get rejected in favor of the less powerful? The same reason why Latin has fallen into disuse: after reaching a certain point, the benefits (and costs) of having more power are trumped by convenience. The reason why programmers flocked to Python rather than Common Lisp is that Python is powerful enough, and much more convenient. Much of modern software development is dealing with technically easy things2, and the benefit from additional power doesn't justify dealing with difficult package management3, awkward string handling4, or the varied and sundry chaos provoked by divergent competing implementations5.

Until CL's inconveniences are dealt with, it won't matter where Lisp rests in the power hierarchy. All languages in heavy usage today are sufficiently powerful for the common tasks they are confronting, and the ones gaining mind-share are those that are more convenient, rather than the more powerful6.

New emerging languages that wish to become mainstream will have to compete first in convenience and second in power. This is why we are seeing a bevy of JVM based languages emerge--piggy-backing on existing Java libraries and the widespread JVM allows great convenience even with limited penetration--and its also why languages that fail to cater to convenience will flounder, even if they are markedly more powerful than existing popular languages.

  1. It has plain speech, polite speech, and three additional varieties of honorific speech. Usually Japanese textbooks begin the explanation with partially overlapping circles and go downhill from there.↩

  2. Web services are often quite simple to program. Difficulties like how to handle scaling require expertise in that problem domain, but the actual implementation is rarely the limiting factor. Many desktop applications are similar. There is a lot of work and detail put in, but the code isn't inherently difficult.↩

  3. ASDF and ASDF-INSTALL are very usable tools, but they lack the simplicity of Python modules and easy_install.↩

  4. Perhaps we have been spoiled by string centric languages like Python, Ruby and Perl, but dealing with strings in Common Lisp is a much less pleasant process.↩

  5. Inconsistent Common Lisp implementations seems to be the root cause of almost every problem with using CL. A proactive and continued effort to develop updated Common Lisp specifications could have helped stave off this fate, but at this point its become rather damning. Its certainly quite possible to develop CL software that plays nicely across most implementations, but its an inconvenience that simply doesn't exist in recent popular languages, all of which have one official implementation. Notably, they all have spawn side projects that are creating unofficial implementations (JRuby for Ruby, Jython for Python, and so on), but those projects all use the official implementation as their specification, and thus have a frequently updated specification to track instead of an incomplete and dated one.↩

  6. This is true for general languages like Python, but it is also true for specialist languages like Erlang. I think we'll see a trend of more domain specific languages that are extremely convenient in their niche (PHP, Erlang), but that it will be hard to develop generalist languages to be markedly more convenient than the current class. Then again, its dangerous to bet against change, especially in a field with as much history for change as programming languages. Following this line of thought, I think that the Nu language will find a healthy niche, but find it unlikely it'll ever survive outside of a symbiotic relationship with Objective-C.↩