The False Uniformity of Oatmeal Code

| 3 Comments

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.

3 Comments

I've always liked that about Perl.

print "Foo" if $foo;
if( $foo ) { print "Foo"; }
$foo and print "Foo";
These may all behave identically, but they read differently. They give hints to the reader, suggestions on the intent of the code, the likelyhood of success/failure, etc.

This is somewhat related work:

http://softwareprocess.es/index.cgi/WhiteSpace

We did a huge study and found that variance/standard deviation of indentation correlated well with McCabe's Cyclomatic Complexity and had a little weaker correlation with Halstead Complexity Measures (sort of like entropy for code).

We also observed that the distribution of indentation used in PHP was more similar to Perl than to other languages :(

One other observation was that PHP code doesn't have a lot of function definitions and if they do they are often shoved off into 1 to 10 files that are included in every php script in the project.

"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."

Yup.

What if Perl didn't have the option of strict and warnings, and it just was? You could never mess it up. It's not that you couldn't tell the difference between good code and bad code, it's that the bad code could never exist.

What if Perl had a built in object system that looked like MooseX::Declare? You'd never have arguments about which object system to use, or why you shouldn't use fields or fiddle about Inside Out objects. You would just use it. And it would work. And if you did something wrong, it would be a syntax error instead of a style error.

What if there was no two argument form of open? What if there was nothing but lexical filehandles? What if you couldn't screw up the new operator on a class? What if you couldn't accidentally use/misuse indirect filehandles?

If you can't get it wrong because it's not a style choice, then you reduce the surface of possible errors. When you have extremely basic choices that you have to make, that if they weren't options wouldn't bring about problems, then you introduce complexity that's not necessary. Users shouldn't have to worry about inheritance structures or how we make our new operators or why indirect syntax doesn't work all the time or as we expect. Those things should just work.

Honestly, I wouldn't mind one bit if Perl trended in the python direction in this area if it made using the language a little easier.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 3, 2010 9:26 AM.

The Fundamental Unit of Encapsulation was the previous entry in this blog.

Punctilious and Parsimonious Primitives is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?