The Programming Language Paradox

Programming language popularity can be measured in two different ways. The first is to look at programming blogs and aggregation websites, and examine which languages as discussed most often. The second is to use a survey such as the one taken by TIOBE to determine rankings. If you do this, then you'll find that the two different techniques give wildly different answers.

The most commonly discussed languages recently in blogs are in no particular order; Scala, Clojure, Haskell, C++, Javascript and Perl. The reasons for some of these are immediately obvious. C++0x is nearly finalized, so blog posts discussing its features are new and interesting. Similarly, Clojure is a recent addition to the Java VM universe, so its pros and cons make good discussion fodder. Finally, Javascript is the language of the Internet, so anything dealing with client-side applications will touch it.

On the other hand, the languages that are most popular according to TIOBE are in decreasing order; Java, C, C++, C#, PHP, Python and VB. Notice how this list looks quite different than the previous one. There is only one common member between the two, C++. Why is it that this survey gives such different results? One possible answer is its measurement technique is faulty. However, this doesn't seem too likely. Java is language of business applications, C the language of low level applications, C++ the language of gui applications and games, C# that of Microsoft .Net, and so on. Each of these are indeed extremely popular, and have many applications and libraries developed in them.

So what is going on? Why is it that people love to talk about programming languages that are comparatively less used? One possible explanation follows.

Programming languages have two goals. The first is the most obvious. The use of a computer language is obviously to communicate with computers. You need to be able to tell the compiler/interpreter/REPL what to do, and a programming language is how you do this. The second goal is more subtle. A programming language is also used to communicate with other programmers. The fact that this second property exists in my opinion is what leads to the difference between the two sets of popularity for programming languages.

Imagine that you never need to communicate with another programmer. (This includes yourself six months from now.) The most efficient programming language is the most powerful and expressive one. The more expressibility you have, the faster and easier it is to program because you can construct larger and more complex abstractions. With this, you can very quickly get the features written that you want to write. i.e. The extra efficiency translates into productivity. The result are programs written with a "global" style.

On the other hand, imagine you need to communicate with very many programmers, some not quite as smart as you are. Then you'll need to use a programming language that is rather less expressive. Things will need to be obvious to others who don't quite know the full picture. This leads to avoiding abstractions which increase complexity, and only using those which decrease it. The result are programs written with a "local" style.

Thus two different use cases lead to two completely different optimal programming styles and thus languages. As a general rule, the languages that are most popular in blog posts tend to be in the highly expressible category. Whereas, the most used languages tend to be in the less discussed but straight-forward low-complexity "local" category.

Is this disconnect a bad thing? Perhaps it is. Having an overwhelming amount of attention paid to programming languages that are rarely used isn't particularly sensible. A common refrain to this is whilst these languages may not be popular now, they perhaps may be in the future. This could indeed be the case, but the situation for Haskell shows that such a highly expressive languages can lie in relative obscurity for decades.

So what language should the average programmer actually use? This is fairly subjective, but noting the above, we have three cases. The first case consists of small projects that are quick to complete. These situations have code which can fit completely in the mind of a single (good) programmer. Here, the more expressible and dynamic the language, the better. Excess complexity isn't a problem, and concise syntax is a blessing rather than a burden. Languages like Perl have made this niche their bread and butter. If this describes your particular problem - go for it. Harness the power of the less used languages, and complete your task in an amazingly small number of lines of code.

However, say your problem isn't quite so small. Here it may be worth avoiding complexity as much as possible. Remember, debugging code is very difficult, much harder than writing it. So if the code is as complex as you could possibly understand, then the bugs within it may be more difficult than you can handle. Also consider that larger problems will involve more people, and often many more people. The enforced straight-jacket approach of the simpler languages may feel constraining, but will pay off in the long run.

This leaves one final case, where you don't actually know how large or difficult your problem is. Here, it really doesn't matter what you do. If the problem is simpler than you thought (unlikely), then you'll waste time writing in a more verbose language. If the problem is more complex and open-ended than you thought, then if you start in a more expressive language you may need to rewrite in a simpler one. (Usually when this happens programmers blame their managers for not understanding the power of language X, or other programmers for not being smart enough to use it...)

Summary

There appears to be two different types of programming languages. Ones that try to be optimally efficient at communication with computers, and ones that aim to be easy for other programmers to understand. The two lead to two different styles of programming. The first tends to require a more global overview to understand program workings, whereas the other tends to optimize for a more local viewpoint. The first set of languages get overwhelming coverage in programming blogs and press, and are used for many small projects. The second set of languages are less talked about, but more used. They tend to be the languages of choice for large projects.

Some languages (like C++) try to fulfill both roles. However, they may or may not succeed at this according to ones point of view. Is C++ becoming so complex now that it is slipping into the first camp? Or is it still possible to maintain a simplistic enough coding style amoungst large groups of programmers to keep it in the second? The friction between the two different styles of programming may explain a large amount of antipathy felt by users of other languages towards C++. By straddling both camps it may be seen to be suited to neither well.

Comments

said...

Enter your comments here

Enter the 10 characters above here

Enter your comments here
Name

• Lockless
• Articles
• The Programming Language Paradox