In Defense of Verbosity

During the fantastic Monad session at PDC 2005*, Jeffrey Snover and Jim Truher illustrated the tradeoff between verbosity and conciseness:

This is a companion discussion topic for the original blog entry at:

So how do your ideas relate to Paul Graham’s?
a href=""


Eh, I don’t buy that. As far as I’m concerned the most readable code is the shortest code that clearly conveys the intended meaning. Reading lots of text is itself an effort that inherently degrades readability.

Sure, reporter shorthand isn’t more readable than plain English. But what about elaborate Victorian style, laden with adjectives and parentheses?

Or a code example: compare “2 + 2 = 4” to “Equals(Plus(Two, Two), Four)”. The second is more verbose, ergo it’s more readable, right? Didn’t think so… the symbols in the first example are both clear and concise, which is the optimum case.

“Even if you think you’re the only one who will read your code”

Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time.

— Alzheimer’s Law of Programming

Katrik, the way I read Graham’s essay, he does not consider the difference between “}” and “End Function” a measure of conciseness:

“I think a better measure of the size of a program would be the number of elements, where an element is anything that would be a distinct node if you drew a tree representing the source code.”


"Ultimately, I think you have to go with your gut. What does it feel like to program in the language? I think the way to find (or design) the best language is to become hypersensitive to how well a language lets you think, then choose/design the language that feels best. If some language feature is awkward or restricting, don’t worry, you’ll know about it.

Such hypersensitivity will come at a cost. You’ll find that you can’t stand programming in clumsy languages. […] someone used to dynamic typing finds it unbearably restrictive to have to go back to programming in a language where you have to declare the type of every variable, and can’t make a list of objects of different types."

In fact, I have a hard time getting from the essay where exactly his complaints about Basic lie. In the first quote, he’s basically (ha) saying that the use of syntactic sugar should not be counted toward the measure of verbosity. Yet he freely says that Basic is verbose. On what basis, then, if a) the number of elements is the same between, say, VB and C#, and b) if (second quote) VB permits dynamic typing, therefore reducing the verbosity of explicit declarations? Perhaps I’m missing something. That happens a lot, actually.

Chris, interestingly you’re showing Basic-like syntax (algebraic) vs. Lisp-like syntax (nested functions), speaking broadly. Yet Basic is considered the more verbose language. Not here, though. So is Basic better than Lisp?

In C-like languages, the tertiary operator is definitely more succinct than the equivalent if() block. It compiles down to the same object code. Is it better? Does it make programming easier a) for the original programmer and b) for those who must maintain the code later?

No one seems to be buying anything!


“I think you mean the “ternary” operator (eg, IIf() in vb)”

Dunno, Jeff – the following is from MSDN (]):

“In C#, an operator is a term or a symbol that takes one or more expressions, called operands, as input and returns a value. Operators that take one operand, such as the increment operator (++) or new, are called unary operators. Operators that take two operands, such as arithmetic operators (+,-,*,/) are called binary operators. One operator, the conditional operator (?:), takes three operands and is the sole tertiary operator in C#.”

uses ‘end’ for everything and it isn’t at all confusing.

Hear, hear. The compiler can certainly sort these things out, so why the extra terms?

(Sorry to clog up your comments, Jeff.)

Reading lots of text is itself an effort that inherently degrades readability

Then it must be really hard to read, you know, English. I don’t buy this. At all. We read so much text every day! Our brains are highly optimized for this task.

You’re really talking about unnecessary code, which I agree is a bad thing. But it has nothing to do with my point about verbosity-- “}” vs “End If”.

the tertiary operator is definitely more succinct than the equivalent if() block

I think you mean the “ternary” operator (eg, IIf() in vb), but I agree. I hate it in both languages. It’s a perfect example of trading off an utterly meaningless one time write-time savings against dozens of read-time comprehension penalties-- It Makes Me Think.

It’s just a bad deal no matter how you slice it.

So how do your ideas relate to Paul Graham’s?

Paul’s point is that high level dynamically typed languages (Perl, Lisp, Ruby, etc) can do more in fewer lines of code compared to your traditional static, strongly typed languages like C#, Java, etc.

It’s really a different point than mine. I’m saying we should use plain, simple English instead of geek-speak when defining language keywords. Failing that, at least give us the option to be verbose or succinct as we please, as shown in my command line options examples.

On the other hand, .NET seems to be evolving towards dynamic languages at a fairly rapid rate, and that’s a good thing!

C# 3.0, VB 9, and D/X/LINQ, the language features being added to .NET are influenced heavily by dynamic languages, eg:

The compiler can certainly sort these things out, so why the extra terms?

Because our brains aren’t compilers? Of course, there is a point of diminishing returns on both sides, but it’s always better to err on the side of verbosity when possible.

Dunno, Jeff – the following is from MSDN (

I can find tons of references to “ternary operator” in google.

To be fair, there are 2x as many google hits for “tertiary operator” (521k vs 260k) so I’m not sure which one is correct.

At any rate, they’re a prime example of the false economy of trading write-time conciseness compared to readability, so whatever they’re called, we can agree on that :wink:

In all fairness, your C vs VB example is quite contrived since it is taken completely out of context and not indented at all.
if (true = isVBVerbose())
Console.WriteLine(“Carpal Tunnel hurts.”);

If (true = isVBVerbose())

Console.WriteLine(“Carpal Tunnel hurts.”)


End If

There is a comparison that is more fair. In any case, if verbosity is great, perhaps the VB team should have called ‘Else’ ‘Otherwise’ since it reads more like English. I just don’t buy it. Interestingly, Ruby (can any language conversation nowadays omit a Ruby reference?) uses ‘end’ for everything and it isn’t at all confusing. It eliminates the need for the End If End While End Function etc. To me, this is a great middle ground.

All this talk of language affordances makes me think of Ken Arnold’s post, Style is Substance:
a href=""

He takes Python’s use of whitespace defining block structure to a logical (perhaps absurd) extension.

To join in the fun I’d add to his list, making the use of uppercase characters in an identifier, and the tab character outside a literal, lexical errors. The formatting differences used to write code tend to be larger barriers to readability then the syntax of the langauge. VB is largely readable because much of the style is enforced by the language rules, rather than simply because it uses tokens with more characters. Also I imagine few VB users use vi, vim, emacs, edlin, etc. making editor consistency another big plus.

One other random point, I always wondered what Python did about tab vs spaces, and finally I looked in wikipedia and found out. They did nothing! a href=""

“The whitespace thing has minor disadvantages. Both space characters and tab characters are currently accepted as forms of indentation. Since they are not visually distinguishable (in many tools), mixing spaces and tabs can create bugs that are particularly difficult to find (a perennial suggestion among Python users has been removing tabs as block markers—except, of course, among those Python users who propound removing spaces instead).”

To my mind that erases the goodness created by the design choice to make whitespace matter. You can write obfuscated Python by mixing tabs and spaces. Doh!

(Yes despite the evidence to the contrary, in my head, these are on topic. :slight_smile:

Adequate programming is whatever consistently works for you.

If writing nearly-unreadable code works for you because you want to save a keystroke here and there, fine then, you go do your thing…


I won’t work with you. None of the people on my team will.

Documentation is the most important part of a program. Developer time is more valuable than any other resource.

So, if we can’t tell at a glance what someone else’s program does, or we can’t tell exactly what a program written a year or two ago does, then it’s useless to us. We do not have the time or the inclination to study programs again and again to rediscover their tasks.

Once compiled, the programs’ll be plenty small and fast.

UNTIL they are compiled, the source code is intended for HUMANS to read. And it had better do a damned good job at that or we’ll throw it out and replace it (and the developer that wrote it!)

Thanks for the clarification, Todd.

That’s a Mortal Kombat style coding fatality! So Mike, consider your virtua spine ripped out.

Here’s a write up of verbosity taken way too far:

“ternary” means “comprised of three parts”, “tertiary” means “the third in a series”. Besides, KR call it the “ternary operator”.

I think the reference in the MSDN docs is a goof especially directly after they use “unary” and “binary”. How about utiary and bitiary? =)

As for the Google results, try putting those terms in quotes and you get 68,100 versus 593, which seems more reasonable.

Entering “tertiary operator” into Wikipedia brings one to “Ternary Operator” which explains the root “arity” and mentions “tertiary” as an inaccurate usage.

I have always liked the iif() function since I first encountered it in dBase III+, but I think that in code as in prose, readability is a balance between brevity and verbosity each in its right place. Sometimes the latter comes after the comment symbol.


But saying what you mean, in English, almost never “just works” and compiles successfully as AppleScript, and so to be productive you still have to understand all of the ways that AppleScript actually works. But this is difficult, because the language syntax is optimized for English-likeness, rather than being optimized for making it clear just what the fuck is actually going on.

Unambiguous, descriptive keywords (eg, not {) is one thing, but I don’t think I’d ever advocate making a language out of English sentence structures.

We definitely want to “optimize for making it clear just what the fuck is actually going on” :wink:

“Sure, reporter shorthand isn’t more readable than plain English. But what about elaborate Victorian style, laden with adjectives and parentheses?”

While taking the point, it could also be noted that Victorian prose contains more detail and shades of meaning than modern styles.

It concerns me a bit that I find it harder to read Darwin than Sagan, because the implication is that people in Darwin’s time had no trouble understanding him, which means I’m not as literate as they were.

VB hurts my eyes to read.

C syntax is simple and elegant.

I really don’t see where you feel that VB gains ANYTHING by substituting END X in for braces.

MS is putting all of its money on C#, not on VB.

C# uses similar syntax, in this respect, to C, not to VB.