Buddy Burden

This is part 4 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at code legibility.

Last week I talked about why Moose is important to my journey as a Perl programmer, and where I feel that it could be even better.  I concluded that it all comes back to code legibility. 

Now, there’s a simple answer as to why I want so desperately for my code to be legible.  I already referenced a blog post by one of those two bloggers I love to hate, Joel Spolsky.¹  In that post, Joel notes (in big, bold letters): “It’s harder to read code than to write it.” And this is one of those places where Spolsky is dead on.  It is harder to read code than to write it ... but the reason for that is that computer languages are designed to be written, not to be read.²  Computer languages are instructional—they consist of a series of instructions to the computer—and everyone knows that it’s easier to give instructions than to follow them.  Well, easier for humans to give instructions; computers seem to have an easier time following them.³  When we read code, we’re not even trying to interpret someone else’s instructions so that we can follow them.  We’re trying to interpret someone else’s instructions so that we can figure out what a third someone—the computer, in this case—did when it followed them, so that we can figure out if it was done properly or not.  If you think about it, that’s quite a difficult task.

So anything I can do to make that task easier, I do.  Even if I have to go to some trouble to do it.

Now, I could tell you that this is because I have, at this point in my life, done more programming as part of a team than solo coding, and therefore I treat others as I wish to be treated.  I could point out that, very often, the “someone else” whose code I’m reading is Younger Me, and Younger Me can be just as impenetrable as Total Stranger.  But all this just scrapes the surface.  Because there’s a deeper, more complex answer to the question of why code legibility is so important to me.

In one of my favorite movies, The Breakfast Club, this exchange takes place between the hardass vice-principal (Vernon) and the savvy janitor (Carl):

VERNON: What did you want to be when you were young?

CARL: When I was a kid, I wanted to be John Lennon ...

VERNON: Carl, don’t be a goof!  I’m trying to make a serious point here ...

Carl, of course, was not being a goof.  He was being completely serious.  My answer to Vernon’s question would be similar: I wanted to be Stephen King.  Of course, I couldn’t literally be Stephen King when I grew up, as that position was filled, but I could have been something similar.  I could have been Neil Gaiman, apart from being 6 years too late and 1 continent too west.  I wanted to write, more than anything else in the world.⁴  My college degree is in English, with a concentration in Writing (as opposed to a concentration in Literature, which is the norm).

In fact, I quite often point out to people—especially other programmers—that I was an English major.  I do this primarily because I believe it says something fundamental about me, because I think you’ll understand where I’m coming from a lot better once you understand this simple fact.  I’m a Liberal Arts person, a creator, a writer of stories ... and now my stories are programs.  Trust me when I tell you that I find coding to be every bit as creative as writing.⁵

When you write, say, poetry, economy of words is crucial.  If it’s metered poetry, you excise words with ruthlessness, and add them only after great deliberation.  But even in free verse, you choose the words carefully and never add more than you need.

But of course poetry is famously hard to read.  Prose is different (not better or worse, just different).  In prose sometimes more words is better, clearer, easier to follow.  Too many words, however, can sound cluttered, and people may lose the thread of the story.  You’ve always got to find just the right balance.  Coding is, for me, prose.  I think too many people treat it like poetry, although I’ll admit I see more and more a change in this.  I’m starting to see people writing in blogs things that I’ve said for years: more comments is not always better, more parentheses is not always better, the most concise formulation is not always the best, self-documenting code is the ultimate goal.

See, to my way of thinking, “self-documenting code” is just another way to say “code that tells a story.” And good code should tell a story.  Well-written code is actually fun to read, not a chore.  There’s the thrill of discovery, as you learn new techniques for dealing with old problems, there’s the suspense of trying to figure out where a particular solution is going and how it can possibly work, and there’s the mystery and wonder of exploring new architectures and new paradigms.  Oh, sure: it can be tricky to read other people’s code.  Their brains work differently, and often they speak an entirely different dialect than you.  For instance, I work with App::Cmd a lot, and Dist::Zilla to a lesser extent, so I’ve read a fair amount of RJBS code.  The experience reminded me a lot of reading A Clockwork Orange, which begins so:

There was me, that is Alex, and my three droogs, that is Pete, Georgie, and Dim, Dim being really dim, and we sat in the Korova Milkbar making up our rassoodocks what to do with the evening, a flip dark chill winter bastard though dry.  The Korova Milkbar was a milk-plus mesto, and you may, O my brothers, have forgotten what these mestos were like, things changing so skorry these days and everybody very quick to forget, newspapers not being read much neither.  Well, what they sold there was milk plus something else.  They had no licence for selling liquor, but there was no law yet against prodding some of the new vesches which they used to put into the old moloko, so you could peet it with velocet or synthemesc or drencrom or one or two other vesches which would give you a nice quiet horrorshow fifteen minutes admiring Bog And All His Holy Angels and Saints in your left shoe with lights bursting all over your mozg.  Or you could peet milk with knives in it, as we used to say, and this would sharpen you up and make you ready for a bit of dirty twenty-to-one, and that was what we were peeting this evening I’m starting off the story with.

It almost makes sense ... but then it doesn’t.  You have to read this stuff for a while, and pay close attention, and occasionally backtrack and reread, but eventually it all starts to come together and feel natural.  And, eventually, you realize it’s brilliant, and you’re ever so glad you took the time to understand the lingo.

So good code is a story, and a story is made up of words.  Now, most programming languages aren’t particularly free with their words.  Steve Yegge has a famous rant⁶ where he discusses what can happen when you unbalance types of words in a programming language.  But even without going to that extreme, programming languages have a tendency to enforce certain idioms.  They have a tendency to create exactly one way to do things, exactly one way to get across a given concept.  This is simpler, they think.  Well, I suppose it is easier to teach.  I suppose that, if the extent of the English you wanted to achieve was the equivalent of “see spot run,” English would be pretty simple to learn too.  But you can’t write stories with that level of expressiveness.  Imagine the paucity of the English language if there was only one, very simple way to say things.  It means imagining English without Shakespeare, without Twain, without Edgar Allen Poe.  Or without Stephen King.  Well, that’s a pretty crappy language, isn’t it?

Perl’s motto is, “There’s More Than One Way To Do It.” Did you ever stop to ask yourself why there’s more than one way to do it?  Because, to tell a good story, you need for there to be more than one way to say things.  You need to use different expressions and different turns of phrase and different vernacular for different situations.  A whole lot of the answer to the question of “why Perl?” for me is because Perl, more than any other language, appeals to the writer in me.  It gives me the best tools to create stories in code.

And there are very specific reasons it gives me those tools.  Which we’ll explore next week.