On the Goodness of Programming Languages

Since my last post on C I have been thinking a lot about what makes a programming language good. This is also motivated by my recent emersion into JavaScript that has me wondering how good of a language is JavaScript. I've had similar thoughts about C++, Java, Lisp and others in the past.

I think that the only sensible conclusion is there is no way to measure the goodness of a language in any objective way. I am certain that I can can come up with a metric that would declare C as the best language ever developed, and another that would make the winner Lisp, or Mathematica or JavaScript. For example if, to simplify things a bit, I decide that the metric for a language's goodness is that:

1. It be functional (first class functions, closures, etc.)
2. It be ubiquitous (available on almost every computing device)

Then it is clear that JavaScript is the best language ever. I can also easily derive a metric that would declare Mathematica as the best language ever (and on some days I am convinced of the absolute truth of this!).

But the truth is that there can never be the best language ever. This is not because programming language technology is constantly (or at least in fits and starts) evolving. The reason there can never be a best programming language begins with the idea of Turing Completeness but it does not end there. Any language worth learning is TC and by that metric is no better than any other. Yet, it is often argued that some languages are more expressive than others (e.g. Lisp is more expressive than Fortran) and therefore one can solve a wider class of problems faster in Lisp than Fortran. But that does not mean there are not valid metrics by which Fortran can be declared the world champion of programming languages.

Humans spend a way too much time debating what the best is. What is the best car, best restaurant, best sport, best OS and best programming language? We do this because we want to be associated with the best. I drive an X, X is the best, therefore I have superior taste. For programming languages such arguments are silly not because we each have our own tastes. They are silly because if you are a programmer and don't sometimes see the superiority of Language A over Language B (and visa versa) then my guess is you are a rank amateur (or really boring person to sit next to at the office). So next time you find yourself in one of those "my language is better than yours" debates (and I've been there too) stop yourself, pick up the best editor :-) and write some code instead!

The Joy of C

My latest assignment at work is to write a very fast message journal. Basically this is a way for writers to stream FIX messages (but could be anything) into a file while at the same time having one or more readers receive the messages. There are numerous little details I am leaving out but they are not important to the point I wish to make.

The programmers who wanted this journal asked me to write it in C rather than C++. Although I usually prefer C++ there was no compelling reason that C++ was needed. To my surprise, I rather enjoyed writing it in straight C and in fact, I am pretty sure the end result is a lot less complex than it would have been in C++.

Don't get me wrong. I am still a fan of OO but the attitude that anything OO is apriori better than pure procedural is a crock of poo. Programming in C forces you to be economical. There is no fancy data structures, templates or virtual functions. There is no Boost or meta-programming. You basically get arrays, macros and some straightforward libraries for threading, I/O and string manipulation. And for many more problems than you might expect, this is all you need.

In C (well written C anyway), you can almost always look at a piece of code and see by inspection exactly what will happen. In OO languages, with virtual functions, this is rarely the case. When you see p->f() in C++ you need to consider p's type and all classes derived from it to imagine everything that might happen. This often incurs a high cognitive load on maintainers of the code. Of course, with function pointers you can create equally obscure C, but you need to work harder in C so you only do that when there is a good reason. C forces you to keep your eye on the ball.

Now, in defense of C++, I have to say that programming in C++ has actually prepared me to be a better C programmer. For example, I treated all my structs as if they were private and wrote interfaces so users of my API never needed to know the internal workings of theses structs. In fact, most of my structs were hidden in private headers or in the .c files themselves. Most of my implementation functions were statics and hence private. This gave me the flexibility to change the internals without breaking user code. OO taught me to think this way. OO also taught me to think about writing code that can be unit tested and to write the tests right after the interfaces were specified but before the implementation. I brought this discipline to C as well.

The one thing truly lacking in C is exceptions. I have to say that exception handling and RAII are two of C++'s strengths. However, with discipline, you can do without these as well.

So if you ever find yourself forced back into a ancient language like C, don't fret. Take the concepts you learned in more modern languages and think about how you can uses the spirit of those concepts to write better code. You just might enjoy going retro!