The Perl Journal October, 2004
I'm surrounded by folks who take language seriously. I work all day in the company of editors, my wife is a high-school English teacher, and a good friend of mine is a linguist. It's a good thing I'm as interested in language as they are, or I would probably fall asleep during dinner conversations.
Language is fascinating because so much about the way we parse meaning out of words is still mysterious. Linguists haven't even begun to really understand how our brains do this amazing thing. Meaning is an elusive thing, both in spoken language and in high-level computer code. In a computer language, of course, we have the luxury of specificity, so exact, unambiguous meaning can be parsed, given enough analysis. If that weren't true, compilers wouldn't function.
In the human brain, it seems that meaning is transferred by a much less precise process, sometimes with hilarious results. In her English class, my wife recently used the phrase "putting on airs." In a student's essay, it came back to her—filtered through the student's imprecise parser—as "putting on ears." I couldn't help picturing a nouveau riche Mr. Potato Head doll trying to fit in amongst old money.
Even in computer code, however, there's a problem with conveying meaning. The problem isn't making the compiler understand what we mean (once we have finished debugging, that is)—the problem is making other programmers understand our meaning. Sure, other programmers can do what the compiler does, and track down the exact syntax behind every piece of code in every subroutine in order to understand what it "means" to use that subroutine, but what we strive for is a much more abstract level of comprehension in those who read or use our code. We want to make it make sense on an intuitive level. So we try to give our variables sensible names, and we try to make subroutine parameters meaningful and intuitive. We try to design configuration files so that users can easily understand the options without repeated trips to the documentation.
But it's not that easy. What makes perfect sense to you might be gibberish to someone who hasn't just spent the last two months of his or her life under the hood of your module. I recently rewrote a bit of my old code, focusing on making the code (and specifically its configuration file) much more intuitive. While the new code is much more flexible, I failed utterly to make it any less difficult for an outsider to understand. I may have even made it worse. It was just a big exercise in myopia.
So what do we do? We certainly can't wait for the linguists to figure out how our brains work. The short-term answer, of course, is to rely on the conventions of understanding that crop up in communities of like-minded people. Perl programmers have certain expectations about the way Perl code should be structured. So get others to read your code and tell you what defied their expectations. That may not constitute a full mastery of the linguistics involved, but at least you'll be using the same shorthand as everyone else, and that will go a long way to helping you get your point across.
Kevin Carlson
Executive Editor
The Perl Journal