TITLE: Patterns as Descriptive Grammar
AUTHOR: Eugene Wallingford
DATE: May 07, 2008 3:20 PM
DESC:
-----
BODY:
I've tried to explain the idea of software patterns in a lot
of different ways, to a lot of different kinds of people.
Reading James Tauber's
Grammar Rules
reminds me of one of my favorites: a pattern language is a
descriptive grammar. Patterns describe how (good)
programmers "really speak" when they are working in the
trenches.
Talking about patterns as grammar creates the potential for
the sort of misunderstanding that Tauber discusses in his
entry. Many people, including many linguists, think of
grammar rules as, well, rules. I was taught to "follow the
rules" in school and came to think of the rules as beyond
human control. Linguists know that the rules of grammar
are man-made, yet some still seem to view them as
prescriptive:
It is as if these people are viewing rules of grammar like
they would road rules--human inventions that one may disagree
with, but which are still, in some sense, what is "correct"...
Software patterns are rarely prescriptive in this sense.
They describe a construct that programmers use in a particular
context to balance the forces at play in the problem. Over
time, they have been found useful and so recur in similar
contexts. But if a programmer decides not to use a pattern
in a situation where it seems to apply, the programmer isn't
"wrong" in any absolute sense. But he'll have to resolve the
competing forces in some other way.
While the programmer isn't wrong, other programmers might
look at him (or, more accurately, his program) funny. They
will probably ask "why did you do it that way?", hoping to
learn something knew, or at least confirm that the programmer
has done something oddly.
This is similar to how human grammar works. If I say, "Me
wrote this blog", you would be justified in looking at me
funny. You'd probably think that what I speaking incorrectly.
Tauber points out that, while I might be violating the
accepted rules of grammar, I'm not wrong in any absolute sense:
... most linguists focus on modeling the tacit intuitions
native speakers have about their language, which are very
often at odds with the "rules of grammar" learnt at school.
He gives a couple of examples of rules that we hear broken all
of the time. For example, native speakers of English almost
always say "It's me", not "It's I", though that violates the
rules of nominative and accusative case. Are we all wrong?
In Sr. Jeanne's 7th-grade English class, perhaps. But English
grammar didn't fall from the heavens as incontrovertible rules;
it was created by humans as a description of accepted forms
of speech.
When a programmer chooses not to use a pattern, other programmers
are justified in taking a second look at the program and asking
"why?", but they can't really say he's guilty of anything more
than doing things differently.
Like grammar rules, some patterns are more "right" than others,
in the sense that it's less acceptable to break some than others.
I can get away with "It's me", even in more formal settings,
but I cannot get away with "Me wrote this blog", even in the
most informal settings. An OO programmer might be able get
away with not using the Chain of Responsibility pattern in
a context where it applies, but not using Strategy or Composite
in appropriate contexts just makes him look uninformed, or
uneducated.
A few more thoughts:
So, patterns are not like a grammar for programming language,
which is prescriptive. To speak Java at all, you have to
follow the rules. They are like the grammar of a human
language, which model observations about how people speak
in the wild.
As a tool for teaching and learning, patterns are so useful
precisely because they give us a way to learn accepted usages
that go beyond the surface syntactic rules of a language.
Even better, the pattern form emphasizes documenting
when a construct works and why. Patterns
are better than English grammar in this regard, at least
better than the way English grammar is typically taught
to us as schoolchildren.
There are certainly programmers, software engineers, and
programming language theorists who want to tell us how to
program, to define prescriptive rules. There can be value
in this approach. We can often learn something from a model
that has been designed based on theory and experience. But
to me prescriptive models for programming are most useful
when we don't feel like we have to follow them to the
letter! I want to be able to learn something new and then
figure out how I can use it to become a better programmer,
not a programmer of the model's kind.
But there is also a huge, untapped resource in writing the
descriptive grammar of how software is built in practice.
It is awfully useful to know what real people do -- smart,
creative people; programmers solving real problems under
real constraints. We don't understand programming or
software development well enough yet not to seek out the
lessons learned by folks working in the trenches.
This brings to mind a colorful image, of software linguists
venturing into the thick rain forest of a programming
ecosystem, uncovering heretofore unexplored grammars and
cultures. This may not seem as exotic as
studying the Pirahã,
but we never know when some remote programming tribe might
upend our understanding of programming...
-----