Arne Vajh?j wrote:
Jan Paulsen wrote:
I'm getting a bit philosophical here, please point me towards a
better newsgroup if I'm too much off-topic.
Anyway, I bet the subject got your attention. Perhaps reading on
will help justify the title.
Recently, I read a post in this newsgroup describing the "select"
technique as a pattern. In case you need a reminder, the "select"
technique is based on a statement of the same name in which you
give a number of channels and the result of the statement is the
result of reading a message from the first channel. The technique
is nothing special to Java, but can also be find e.g. in functional
languages.
This led me to wonder a bit about our usage of the word "pattern",
which I would very much like your input about.
Besides the common notion of a "pattern", there are more
academically precise notions. There's the GoF book describing
design patterns, Alexander gave the origins to the paradigm in his
seminal work on architectural patterns, Lynn and Manns gave an
introduction to the personal leadership of change using patterns,
we have even learned about anti-patterns in analysis and no doubt I
have forgotten some important works.
However, it seems to me that common use, as was the case of the
post mentioned in the beginning of this article, is that almost
everything is regarded as a "pattern" if there's some repetitive
nature to the observation.
So, are we starting to use the common notion rather than the
academically precise and well-researched definitions? That is, do
you often say to your colleges that "I have this pattern in my
code" where you are not referring to a well-defined pattern, but to
some custom or, as I call it, technique? Are you, sitting in the
canteen, telling about "patterns" in your methodology when you
cannot pinpoint the origin of the pattern you are talking about? Or
do you see some other uses of the term "pattern" when it is not
well-defined?
Again, sorry if I'm off-topic, just started to wonder.
I don't see much difference between academic and common use
of the word.
Both see it as "a recommended solution for a specific problem".
A difference in level of documentation does not imply a
difference in opinion.
And it is hardly surprising that someone writing a book
about patterns document them better than a team trying
to deliver a web app on time and on budget.
Sure, of course, agree, with you all the way. What I'm trying to
convey by the expression "academic use" is that they're usually
pointing at some article or book and saying that's the origin of the
term. I may be wrong, of course, but that's my impression. And, yes,
I may be seen as nitpicking.
The difference between someone writing a (well-researched) book and
someone delivering a project on time and on budget is precisely, in
my opinion, the difference between academics and practice. I respect
both deeply.
But the difference is generic for the contexts. You will see