Pragmatic (programming) language use

While doing research for an earlier post, I wondered whether the pragmatic programmers had ever come up with a definition of a "pragmatic language" in which to do one's pragmatic programming. They had not - at least none that Google was aware of.

If I'd given it any thought, I would have realized that it's not particularly pragmatic to divide programming languages into "pragmatic" and "non-pragmatic" categories. The pragmatic approach is to pick a language that's appropriate for your current project and learn to use it well, not to engage in holy wars about which languages are better than others.

Anyway, the first two hits on a Google search for "pragmatic language" led to the website of the American Speech-Language-Hearing Association, which defines pragmatics as the ability to use language appropriately in social situations. That was kind of interesting, but didn't seem germane to software development in any way - until I read this:

An individual with pragmatic problems may:

• say inappropriate or unrelated things during conversations
• tell stories in a disorganized way
• have little variety in language use

Hey, pragmatics and pragmatic programming have something in common after all! Let's examine the symptoms, shall we?

Say inappropriate or unrelated things during conversations

If we substitute "programs" for "conversations", this becomes highly apropos to programming. One of the key concepts of pragmatic programming is to design components that have a single, well-defined purpose. If a component deviates from that purpose to do something unrelated, that's a code smell. Time to refactor!

Tell stories in a disorganized way

The legendary Donald Knuth introduced the concept of literate programming, which holds that it's not sufficient for a program to instruct the computer what to do; it must also explain to human beings what the computer is supposed to do. Knuth suggests that a literate programmer can be considered an essayist, and Yukihiro "Matz" Matsumoto, the inventor of Ruby, affirms this view in "Treating Code As an Essay" (Found in the excellent O'Reilly compilation"Beautiful Code".) If we agree with these wise gentlemen, then surely code must tell its "story" in an organized way to qualify as an essay.

Have little variety in language use

If a programmer employs a limited variety of coding strategies, it suggests that Maslow's hammer - "If all you've got is a hammer, everything looks like a nail" - might be to blame. This can happen when an inexperienced programmer first discovers design patterns, and becomes so enamored with a particular pattern that he or she applies it everywhere, even when it's not appropriate.

An alternative interpretation of this symptom is an unwillingness to learn or use programming languages other than the one a programmer is most familiar with - let's call this monoglot programming, to contrast it with the increasingly popular practice of polyglot programming.

I'm not suggesting that pragmatics and pragmatic programming have any deeper connection than this. Language pragmatics are innate, whereas pragmatic programming must be learned. I'm certainly not implying that a deficit of pragmatic programming skills indicates a possible brain injury! But it's interesting to see how easily deficiencies in the domain of language development can be recast in terms of software development, despite being linked only by a coincidental overlap in terminology.