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.