Concision v. Clarity

Recently, the reinvigorated programmer blog ran a series, "Why ___ is not my favourite programming language".  He covered C++, Perl, Javascript, C, Ruby and Java and posts were basically excerpts from standard manuals that, in most cases, demonstrated aspects of the language which allowed the incautious programmer to easily write buggy code.  The charm was that these weren't obscure byways in the languages, these were main thoroughfares.  A very funny series.

The series ends with a post on what his current favourite language is and his argument is quite interesting.  Basically, he comes down to choosing between Java and Ruby and goes with Ruby, preferring it's concision.  Usually, the concision argument is pretty easy to mock because all too often concise == inscrutable, but it's worth going over and looking at his pro-concision bullet points, it's the best defense of concision I've seen.  He spoils his point a bit with a Java v. Ruby example where the Java example could have been much cleaner, but still, point taken.  Newsflash, Java isn't an especially concise language.

I don't know Ruby and I'm not writing this post to defend Java, but I would like to make one small point in Java's favor.  Java (and Pascal) are verbose, strict languages.  The nice thing about this is they tend to be self documenting and they don't let you make a lot of stupid mistakes.  How often did I write

if ( a = b )

in C?  Often enough so that I got really good at recognizing the symptoms of the mistake and finding it quickly.  Java won't let you do that at all and saves a lot of time because of it.  Back when the comparison was relevant, I used to say that a project could be done in C more quickly, but the same project done in Pascal would be more robust and require less maintenance and would cost less in the long run.

This is the foundation of my "downside of concision" argument.  You may be able to accomplish more with less, but how maintainable is it?  Many years ago, I was maintaining some chunk of legacy code and ran across a line that looked like this:

<var> <var> <var> <var>

Hmmm.  Wonder what that does?  The manual was no help - where are you going to look?  There's no syntax there to go to the index with.  After some spelunking on my own, I was able to determine that the first variable seemed to contain a file name and after knocking on the doors of several senior developers I finally found one who vaguely remembered what it did.  This was 20 years ago, so I'm sure I'm not remembering exactly, but the upshot was something like: var 1 is a file, var 2 is a column in the file, var 3 is a pattern.  Do a binary search on the file in the column for the pattern and put the line number in var 4.  Admirably concise!

My point is this.  The language is only part of the problem.  Being able to write it quickly and, later, being able to read it quickly isn't the same as being able to understand it quickly.  Any line of code that you write, you should ask yourself, when I come back to this in 6 months, am I going to know immediately what it does?  If yes, one gold star.  The next question is, can somebody else come up to this line of code and immediately know what it does?  Two gold stars!  For three gold stars: can somebody who isn't that familiar with the language look at the code and know immediately what it does?  A very high bar indeed.  Some languages help you write easily understood code more than others, some languages fight you every step of the way (I'm looking at you, Perl).  If the language works to obscure your intent, verbosity and comments are allies.  In the end, clarity is the programmer's responsibility.