Immanuel Kant: Mattson's Pattern Language

Most any attempt at taxonomy is inherently flawed, or at least incomplete.  There is no objectively clean way in which a complexly interwoven system can be described both completely and succinctly.  You can see this in biological taxonomy, which struggles to incorporate genetic history into a timeless label (birds share the same superclass as dinosaurs and mammals, incorrectly suggesting their common ancestor).  You can see this in medical taxonomy, which struggles to describe the symptoms, causes, and circumstances around the disease in a single label (resulting in dozens of competing standards used by different groups in the industry to describe similar things).  Yet biological taxonomy is immensely useful.  Medical taxonomy is immensely useful.  Neither is perfect, but both highly functional.

Entire fields of philosophy are devoted to exploring the ways in which we are shaped by the organization we impose upon something.  This is a particularly interesting question in computer science for two reasons:

1. We have the ability to organize information into any conceivable way: a pattern language isn't merely a labeling of natural phenomenon, it is a fundamental way of conceiving the organization of information itself.
2. We use and build upon our taxonomy more than almost any discipline: a program consists of millions of inter-related components existing at dozens of levels of abstraction.  Each new contribution is defining something new, and is likely to be the foundation of something else.  Thus how we think about it affects how we actually do other things that haven't yet come up.

Curious as to the epistemological significance of such qualification, I fired up the GRUMPS and had a quick cup of coffee with Immanuel Kant.


Kurt: Immanuel, in trying to organize a new system of knowledge, what is it that I'm seeking?
Kant: Experience without theory is blind, but theory without experience is mere intellectual play.
Kurt: So in constructing a language, I'm primarily seeking to guide and organize my thoughts?
Kant: All the interests of my reason, speculative as well as practical, combine in the three following questions: 1. What can I know? 2. What ought I to do? 3. What may I hope?
Kurt: So it should be comprehensive, practical, and illuminating?
Kant: Intuition and concepts constitute the elements of all our knowledge, so that neither concepts without an intuition in some way corresponding to them, nor intuition without concepts, can yield knowledge.
Kurt: Then it should be accurate, and intuitive as well, I see.  Thank you muchly for your time and words.



Though a taxonomy is inherently imperfect, they can still be good.  So how would Kant's questions apply to a pattern language?

1. It should help a developer be more productive: a good taxonomy of patterns will help a developer think in a way that clarifies their understanding of their system at as many layers as is pertinent.  It should given them a practical layering of concepts, and provide relevant ideas at each layer.
   
2. It should be easily expandable: no taxonomy is permanent, least of all in the world of programming.  A new pattern should have an obvious place in the language, and pertinent, identifiable relationship to other ideas based upon its placement.
3. It should be as simple as is practical: the more effort is required to understand it, the less people will use it.

So how does Tim Mattson's concurrency pattern language stack up?

1.  Would it help a developer be more productive?  It's hard to answer this without actually referring to it during the creation of a program, but I like how he cleanly distinguishes between the various roles of software engineers, and organizes his language accordingly.  That said, I don't know the chances that a developer would benefit from looking up a list of patterns so broadly categorized.
   
2. Is it easily expandable?  This structure doesn't draw much of a relationship between categories, and can be a bit questionable in the consistency of its abstraction layers.  Is a pipeline an algorithm strategy or an architectural pattern?  He puts it in both categories without explicitly explaining the difference in their use.
   
3. Is it as simple as is practical?  It's certainly simple, and easily understood.  There is a chance it's too simple, providing too little guidance as to the niche of various algorithms and approaches.

Maybe "pattern language" is a bit of an overstatement in describing the system.  It's more like a group of lists for developers of varying focus.  This isn't a bad thing--it could be a handy reference for a developer looking for ideas to address a specific concurrency problem.  The title is deceptive, however.