The False Uniformity of Oatmeal Code

How can you tell the difference between good code and bad code?

Hold that thought. Can you tell the difference between David Foster Wallace and Ernest Hemingway? Here's something in the DFW style:

And but so, walking beneath the faux-Greek[1] architecture crumbling and rotting away in the murk of the autumn, an autumn which had not so much descended as creeped up upon the city from the bay, rolling up from beneath flat-bottomed ships and barges where dockworkers laughed and swore and jabbed at each other, questioning parenthood and manliness, there a soiled plastic bag crinkled and cried beneath my feet, squawking its millennia-long half life, and there the acrid sky scowled down on me like an angry god.

(The footnote itself has a footnote.)

The Hemingway style is also distinctive:

See the man. The man is old. See the sea. The sea has fish. Fish, old man, fish. Die, old man, die. War is hell.

Programming languages can be as expressive and idiomatic as natural languages, and they govern how you write in them. (So do coding guidelines and dialects and standards and idioms: if you're Theodor Geisel or Ernest Hemingway, you get sentences of four to seven words, no complex clauses, and, by gum, you don't get footnotes. If you're DFW or another pomo hero, you cram and glue separate sentences together with whatever punctuation is at hand, and if you tell a coherent story, cut it up and paste it together and pretend you didn't steal the technique from William S. Burroughs.)

One important difference between source code and literature is that aesthetic qualities are secondary concerns for source code.

Even still, you can't discount it. Obviously bad code can have warning markers, and that is itself a useful characteristic: you can tell it's bad code just by looking at it.

(The word bad here is ambiguous. Is it bad because it has subtle bugs of implementation? Is the algorithm wrong? Does it have obvious or non-obvious failure conditions? Does it meet the specification? Is it maintainable? Does it have security problems?)

Here's the interesting thesis: languages which allow you to write ugly code let you skim programs to find bad code. Languages which force you to write uniform code take away your ability to skim programs to find bad code.

In other words, the superficial visual differences between good Lisp code and bad Lisp code or between good Python code and bad Python code or good assembly code and bad assembly code or good Java code and bad Java code (or good Befunge and bad Befunge code, if you haven't had enough DFW yet) are smaller than the superficial visual differences between good Perl code and bad Perl code or good C code and bad C code or good C++ code and bad C++ code or good PHP code and bad PHP code.

(Statistics lie slightly; the difference is likely one of standard deviations rather than absolute values.)

This characteristic may hide a small irony: Hemingway may be easier to skim than David Foster Wallace, but skimming Hemingway may lead you to skip over important small subtleties which a detailed reading can reveal. (It's an imperfect metaphor: that would require Hemingway to have had the ability to include subtlety in his writing.)

Put another way, if the natural tendency for writing code in a language produces code uniform within a small standard deviation, it's difficult to write code that's obviously right and code that's obviously wrong — and isn't that a characteristic of good APIs? The right code should be obviously right and incorrect code should give you the howling fantods because it's so obviously wrong.