Jokey Code?
Choose Talks
I usually leave it as late as possible before deciding which sessions to attend at the ACCU conference. There’s ample time to study the schedule when you’re there and anyway, it’s subject to change.
This year I stuck with this policy with a couple of notable exceptions. First, there was my own talk, where I noted that computer programmers are writers who impose formal constraints on their texts, and who can learn from other writers who practice the same discipline. Second, there was Peter Hilton’s talk, “How to name things — the hardest problem in programming”, in which he argued more generally that programmers had much to learn from writers.
I had to see Peter Hilton’s talk and it did not disappoint. It engaged me at the time, in discussions afterwards, and it continues to make me think. I won’t post a full response here but I do want to consider one aspect: humour.
Tell Jokes
Peter Hilton argued we should pay attention to tips from the likes of George Orwell and Stephen King because their advice is better written and also because it’s funnier. Why does this humourous aspect matter? Well, perhaps we’re more likely to listen to someone who makes us laugh. Witty advice sounds less pompous.
It goes deeper than this, though. Another point from the talk:
Improve your general vocabulary. Read books, especially funny novels.
Why funny novels? At this point in the talk Peter Hilton disingenously suggested such books were easier to read. A point he made later goes deeper:
Tell jokes … Puns are important for naming, because they rely on double-meanings. Spotting double-meanings is the essential skill for avoiding ambiguous names.
Interesting! I agree that word play and word power are linked: but do you need to be a punster to avoid ambiguity? I’m not sure. In the words of Chris Oldwood:
I’ve been writing more functional code lately. I recently tried a few numerical recipes with currying functions, but all I got was a NaN.
Laughable Code
Is there a place for humour in code? Rarely, I’d say. Code is read, re-read and then read again: most jokes become tired and then irritating under such scrutiny. Peter Hilton, though, described his amusement on discovering this function, which configures and starts Apache Camel:
/** Configure and start Apache Camel */
def mountCamel() {
Logger.info("Starting Camel...")
val context = new DefaultCamelContext()
configuredRoutes foreach { route =>
context.addRoutes(route)
}
context.start()
}
The obvious alternative, startCamel(), just isn’t funny enough, apparently. I’m glad the author resisted the temptation to call it humpCamel().
I’m reminded of a colleague with a fondness for franglais who
would, for example, check in a graphics routine called
do_le_render(). Mildly amusing first time round, maybe, but less so
each time it got revisited to fix les bugs.
I don’t see many jokes in the code I read and I don’t think it’s because the authors lack a sense of humour. Just as good documentation should inform rather than entertain, good code should express complex ideas as plainly as possible: humour doesn’t get a look in.
There are exceptions. We’ve already seen the name “camel” used for something which isn’t a camel: libraries, products and projects can benefit from short, memorable and quirky names. In unit tests, too, code is less complex, which can leave space for quips and in-jokes. When an integer is expected it often turns out to be 42. Binary input data is laid out to form strange messages when viewed as hexadecimal. If some text — any old text — is needed, lorem ipsum would indicate a lack of imagination. Even so, well-chosen names and values from the domain under test would probably be more helpful when a failing test needs fixing.
Charming code
I’m down on jokes in code but I do think code can be a pleasure to read and that well written programs can delight. Whilst I agree with Peter Hilton’s recommendation to read widely and well, I was surprised he didn’t recommend reading code, and when I discussed this with him afterwards he asked, where is it? Where is it! That will be the subject of another article, but off the top of my head, freetype, ffmpeg, llvm, the Go and Python standard libraries. If you read through any of these you’ll enjoy their clarity and internal consistency — their style; and should you code against them, these same attributes show through their interfaces.
I haven’t found any jokes in the SQLite source but if you decide to integrate it in your application, when you check the license you’ll find, instead, a blessing. This may seem funny — unusual, certainly — but it’s actually quite serious.
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
We may not issue blessings with our own code but maybe we can find other ways to surprise and delight.
Articles