Succinctness < Clarity

Paul Graham has suggested that the great goal of a programming language should be succinctness.

On reflection, I would argue that if being succinct were truly the ne plus ultra of programming, we'd all be using APL. Alternately, we'd be using Lisp... but despite Paul Graham's obvious predilection for Lisp, it never became the language of choice for commercial software development. So why not?

As someone who (after earning a CS degree) has toiled in the trenches as a working programmer for a couple of decades, and who's also been a project manager for some of those years, what I've come to believe is simple if unexciting: terse languages are harder for normal human beings to maintain than simpler (and therefore more verbose) languages, and a necessary requirement for a commercially effective programming language is that programs written in it are simple enough for normal human beings to understand and maintain.

The first part of this argument speaks to the people who actually use computer languages in commercial environments to build functional software systems. Although universities attract the people who are comfortable enough with abstractions and theory that they can get used to content-rich procedural languages, businesses hire practical programmers who are most comfortable with simple imperative statements. Those are the folks who are available for hire to crank out code.

Not surprisingly, then, programming languages that clearly spell out what a computer should do become most popular among those who must not only write programs but who also need those programs to be understood and modified later by other typical programmers. Languages like Lisp and Prolog are too high-bandwidth; they are so succinct that they pack too much information into the typical page for the average programmer to grasp at a glance. This is also the problem with baroque Unix-flavored scripting languages like Perl -- a program that does anything useful is too dense for the normal business programmer to understand without spending a lot of time groveling over it.

The second part of this argument concerns the value of apparent verbosity. Why does English retain articles like "the" and "an?" We don't need them -- other human languages don't have them -- but we still use them. I'd submit that these bits of syntactic sugar survive because they have value in understanding speech. They give our brains time to comprehend the nouns and verbs we hear before the next batch come at us. Similarly, I would not be surprised that more "verbose" languages like C and Java survive (and even thrive) in commercial environments versus more succinct languages like Lisp because the former are designed to have enough filler to allow the average programmer to understand one page's worth of the typical program.

That's not to say "more filler equals better language." There's a limit beyond which you wind up fighting with the formalisms instead of coding useful commands (see COBOL). Instead, what I think this means is that there is a proper balance point between succinctness and clutter. A commercially effective programming language will include some simple connective elements in addition to the verbs and nouns so that the average person who gets hired as a programmer isn't overwhelmed by pure content.

In summary, then, I can't agree that succinctness is a proper goal for a commercial programming language. I'd never claim that BASIC or C or Java are perfect languages; I've had my compaints about all of them from time to time. But I would say that those languages have enjoyed their times of popularity for business software development in part because they are not succinct, because they put just enough of the right content on a display page to allow the average working programmer to understand what that piece of code is supposed to be doing.

If there's a word that describes that quality, perhaps it's "clarity." That doesn't quite capture the nuances of "balance between content and syntactic separators" I'm looking for, but it's close.

So as an alternative viewpoint, I'd have to say that in a business environment I'll take clarity of code over pure succinctness any day. I can get more work done with a programming language designed to generate programs that the average programmer can understand than I can with a language whose code is so elegant that only the highly-trained expert can grok it.