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.

Review: Clean Code

"Clean Code"by Robert C. Martin is not a conventional programming book. It's not about a new language, framework, methodology or tool. It's about how to be a better developer.

As such, it has much in common with books likeCode Complete,Effective Java,The Pragmatic Programmer,Refactoring, andImplementation Patterns, all of which fall into a genre I've dubbed "self-help books for software developers". I'm not being dismissive here: after all, systems can be just as dysfunctional as families. As developers, we can benefit from some good advice on how to cope.

Much of the advice that "Uncle Bob" dispenses will be familiar to readers of those other books. (Indeed, "Clean Code" references "Refactoring", "Implementation Patterns" and "The Pragmatic Programmer" quite extensively.) I find this redundancy comforting rather than disappointing. After all, if all these books disagreed about what the best software development practices were, how would you know which advice to follow?

(However, there is a certain irony in having read about the DRY principle - "Don't Repeat Yourself" - in three different books.)

Despite the commonalities with its predecessors, "Clean Code" is more than just a rehashing of old advice. The unique aspect of "Clean Code" is the section near the end of the book where "Uncle Bob" uses the principles laid out in the preceding 12 chapters to refactor samples real-world code drawn from the JUnit testing framework, the JCommon library, and his own work.

It was fascinating to see perfectly functional code iteratively refactored into "clean code" much better suited for reuse and further extension. Other books have explained this principle and demonstrated it on small pieces of example code, but only in "Clean Code" have I seen it applied to widely-used open-source code.

If you've ever wanted to refactor some dysfunctional code but not known where to start, or doubted that the end result would justify the effort, you should read Martin's book; it will give you the hope and confidence to give it a try.