2007-12-22

Why is everyone so afraid of a bit of typing?

Often when people discuss programming languages I see people emphasize the amount of typing needed to express the same constructs in different languages. There is often a lot of enthusiasm whenever some construct can be expressed with fewer tokens. While less typing is generally a good thing in a profession where the spectre of carpal tunnel syndrome lurks in the shadows at all times, I think some people over-emphasize how important compact notation is.

For me, the "power" of a good programming language is not how few characters you need to type in order to achieve your goal, but how clear the result is -- how easy it is to read the resulting code and understand both intent and what it actually does. For instance: I've seen a lot of very compact Perl code in my time, but a lot of this code is also hard to read and makes use of subtle nuances in the language that may not be apparent to a novice Perl programmer. I think this is problematic. And indeed, much of the Perl culture is about celebrating these somewhat obfuscated idioms; which I find to be highly counter-productive.

Java has had to endure a lot of criticism for its verbosity and the fact that it does not invite the programmer to do quick hacks. I am not necessarily convinced this is a great weakness of the language.

Most of the struggles I have had with Java are with rather baroque frameworks and bad APIs -- not with the fact that for instance Map types need to be declared and that you have to call methods on them in order to mutate them or access their data -- as opposed to dictionaries in weakly typed scripting languages. When I struggle in Java it is most often because I am using libraries where the author didn't pay attention to the API -- where the author didn't understand that I am not really interested in how their XML parser works; I just need to parse, or write, some simple XML files.

Most of the code I write falls into one of two classes:
  • Hacks
  • High value code
"Hacks" are programs that usually just solve some small practical problem. For instance I have a lot of hacks that do things like clean up files, automate tasks that are tedious to perform manually etc. Most of these are just used by me. Some of them are just used once or over a short period of time. They do not need to be maintainable. Nor does anyone but me need to understand how they work. They are rarely extended or developed further. For "hacks" any language will do as long as it enables me to get a result quickly. Perl, Emacs-Lisp, Python, Shell script usually allows me to get things done quickly.

For "high value code" things are very different. It is likely that once written, a piece of code will be used for a long time and by a lot of people. The code needs to be clear, it must be structured sensibly, it needs to have proper tests and it needs to have good APIs, both internally and externally. It should also give future developers some ideas on how to extend it or change it. Since "high value code" has a longer life-span and a wider audience, it makes sense to spend more time writing it. The time spent writing it will almost always be eclipsed by the amount of attention other people (including you) are going to pay to it. This is where clarity always has to be the priority. I think it is easier to achieve clarity in languages like Java. Yes, some things will be more verbose than, say, a weakly typed scripting language, but does it matter?

I am not saying overly verbose code is better. I am just saying that for "high value code" compactness isn't nearly as important as when you just need a quick hack. The code is going to be around a while so any time spent up front making it readable to a greater audience, is time well spent. It will pay off later.

No comments:

Post a Comment