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