What's a pattern?

[Wojtek]

Jan Paulsen wrote :

Nice question! I would say "no" in the academic sense but "yes" in the common
sense. This means I would but careful to define it as a pattern in daily use.
The thing is, we need much more evidence that what you're doing is a common
scenario (I think it is).

But how much do we need? Are we able to put a
specific percentage of the number of observed applications to this? Or is
some other way of setting the bar required?

(and, to make it clear, I'm absolutely sure your good use could easily evolve
into a well-defined "pattern", but not without changes to accomodate for
generalisation)

Well, I call it a pattern, especially when I was creating it with all
the error/fix cycles, until I got it to work (damnit!). But I was
careful to apply every change to all the other places, so the code
everywhere works the same.

Which is the hallmark of a pattern IMHO. It is just that this pattern
is a LOT more involved than the usual pattern definition I read about.

Maybe a pattern in the general sense should be "simple" in that it does
not involve many hundreds of lines of code to implement (or pages of
text to explain).

 

[Jan Paulsen]

Jan Paulsen wrote :

Well, I call it a pattern, especially when I was creating it with all
the error/fix cycles, until I got it to work (damnit!). But I was
careful to apply every change to all the other places, so the code
everywhere works the same.

Which is the hallmark of a pattern IMHO. It is just that this pattern is
a LOT more involved than the usual pattern definition I read about.

Maybe a pattern in the general sense should be "simple" in that it does
not involve many hundreds of lines of code to implement (or pages of
text to explain).

I think you're right. And cheers for getting the damn thing working! I
think (and I'm getting a bit tired of being so philosophical today) what
you're looking at is an emerging pattern. For me, a "pattern" (in the
academic sense) would need to undergo so analysis for generalisation and
extracting what's important and not much more.

Thank you very much for you're input; I don't know why, but I find this
topic quite interesting (of course, I'm about to start a thread entitled
"What's beaty?" in accordance with the lot of "Beautiful <favourite
topic here>" books coming out).

Again, nice to hear,
Jan Paulsen

 

[Dirk Bruere at NeoPax]

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.

Regards,
Jan Paulsen

In general terms a pattern is an algorithmically compressible structure.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Wojtek]

Jan Paulsen wrote :

what you're looking at is an emerging pattern. For me, a "pattern" (in the
academic sense) would need to undergo so analysis for generalisation and
extracting what's important and not much more.

Well, it is cross-language also. The whole thing together uses:
Java
SQL
XML
JavaScript
AJAX
JSP
DHTML
CSS

I would hate to have to try to make it generic, plus it has a very
tight fit into the framework we developed.

 

[Roedy Green]

here's a language difference here, because I use the work "pattern" to
describe one of those entities,

e.g. java.util.regex.Pattern which has nothing to do with GoF
patterns.


See http://mindprod.com/jgloss/gof.html

--
Roedy Green Canadian Mind Products
http://mindprod.com

"Let us pray it is not so, or if it is, that it will not become widely known."
~ Wife of the Bishop of Exeter on hearing of Darwin's theory of the common descent of humans and apes.

 

[Arne Vajhøj]

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.

Arne

 

[Jan Paulsen]

In general terms a pattern is an algorithmically compressible structure.

Nice!

But then what with those design patterns from the GoF book I keep coming
back to? Would we call them algorithmically compressible or not? There
seems to be some discrepenacy here since patterns as in those books I
mentioned should be incompressible in some sense since they should
convey what's important and not much more. However, I have trouble
bridging the gap between the generel term "patterns" as defined in those
books to "algorithms" as a mathematical "recipe".

Could you please tell me where I could look up that definition of
pattern as an algorithmically compressible structure? Sounds like an
interesting topic.

Regards,
Jan Paulsen

 

[Jan Paulsen]

e.g. java.util.regex.Pattern which has nothing to do with GoF
patterns.


See http://mindprod.com/jgloss/gof.html

Yup, there's a completely different take on "pattern" as a pattern in
regular expressions. You're hitting it spot on when pointing out that my
language use is not consistent with what I say it is like What I
wouldn't give for listeners to hear what I think as opposed to what I say...

Regards,
Jan Paulsen

 

[Arne Vajhøj]

e.g. java.util.regex.Pattern which has nothing to do with GoF
patterns.

Design pattern and regex pattern should be clearly
distinguishable by context.

Arne

 

[Jan Paulsen]

Jan Paulsen wrote :

Well, it is cross-language also. The whole thing together uses:
Java
SQL
XML
JavaScript
AJAX
JSP
DHTML
CSS

I would hate to have to try to make it generic, plus it has a very tight
fit into the framework we developed.

Still, I think that it would be nice to see generalisations of such an
application. Perhaps we'll see some "Cross-language design patterns" book?

Regards,
Jan Paulsen

 

[Jan Paulsen]

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.

Arne

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.

Regards,
Jan Paulsen

 

[Dirk Bruere at NeoPax]

Nice!

But then what with those design patterns from the GoF book I keep coming
back to? Would we call them algorithmically compressible or not? There
seems to be some discrepenacy here since patterns as in those books I
mentioned should be incompressible in some sense since they should
convey what's important and not much more. However, I have trouble
bridging the gap between the generel term "patterns" as defined in those
books to "algorithms" as a mathematical "recipe".

Could you please tell me where I could look up that definition of
pattern as an algorithmically compressible structure? Sounds like an
interesting topic.

If you want to rush off in that direction you rapidly end up with
complexity theory and definitions of randomness

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Robert Klemme]

That said, I have to disagree just a bit with you. I agree that the GoF
book by no means exclusive rights for the term, but the word "pattern"
is, as so many words, loosely defined in common use, but has a precise
definition as well, to me, as handed down by books describing the
patterns all their gory detail with sound reflections based on research.
Call me sour, in which case I'm sorry (put in full-stops for me, please).

When you say "precise definition" you make it sound like "scientific"
(for me at least). Although I would concede that GoF and other authors
have vast experience in the domain I am not as sure about the scientific
approach. For me the term "pattern" or "design pattern" is only mildly
precise. And the patterns as defined in "the book" are even less
precise which you can see from the fact that some patterns are quite
similar or at least related that there is not necessarily a clear
distinction.

Often people say "I implemented pattern X here" which can help
communicate the idea but for me the main advantage of patterns is as a
crystallization point for reasoning about interactions between objects.
I tend to find out that I used a pattern X somewhere after the fact
most of the time, i.e. I do not consciously select particular patterns
but rather try to find the constellation that fits the problem best.

I'm just having too much time this evening, I know, and to be sure, I'm
not particularly hung up on the subject - and indeed agree that "if it
works, stop thinking so much about it".

Good approach.

Kind regards

robert

 

[Jan Paulsen]

When you say "precise definition" you make it sound like "scientific"
(for me at least). Although I would concede that GoF and other authors
have vast experience in the domain I am not as sure about the scientific
approach. For me the term "pattern" or "design pattern" is only mildly
precise. And the patterns as defined in "the book" are even less
precise which you can see from the fact that some patterns are quite
similar or at least related that there is not necessarily a clear
distinction.

Often people say "I implemented pattern X here" which can help
communicate the idea but for me the main advantage of patterns is as a
crystallization point for reasoning about interactions between objects.
I tend to find out that I used a pattern X somewhere after the fact
most of the time, i.e. I do not consciously select particular patterns
but rather try to find the constellation that fits the problem best.


Good approach.

Kind regards

robert

Well said. I think I'm slowly taking a contradictory point of stand,
which is not what I wanted. I just wanted to say that when I use a
"pattern", it's something I read in those books, when I use my native
tongue for the same word, it's something much looser. Whether those
books are scientific or not is another discussion, I think.

Regards,
Jan Paulsen

 

[Jan Paulsen]

If you want to rush off in that direction you rapidly end up with
complexity theory and definitions of randomness

That's what I was hoping. Loved Papadimitrou, but it's been a while.
Reference, please? Someone?

Regards,
Jan Paulsen

 

[Arne Vajhøj]

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.

It is part of academic procedure to trace it back to original inventor
and give proper credit while a project does not care if it works.

But the difference is generic for the contexts. You will see
similar difference between researchers in political science and
active politicians.

Arne

 

[Jan Paulsen]

It is part of academic procedure to trace it back to original inventor
and give proper credit while a project does not care if it works.

But the difference is generic for the contexts. You will see
similar difference between researchers in political science and
active politicians.

Arne

Okay, that I simply did not understand. I got the part about finding the
original inventor and give credit where itøs due, but I think a project
does care if it (the project?) works. Then I simply don't understand
"the difference is generic for the contexts". I don't get it. I think
we're talking about rather (excuse me) banal differences between
researchers and practitioners.

regards,
Jan Paulsen

 

[Arne Vajhøj]

Okay, that I simply did not understand. I got the part about finding the
original inventor and give credit where itøs due, but I think a project
does care if it (the project?) works. Then I simply don't understand
"the difference is generic for the contexts". I don't get it. I think
we're talking about rather (excuse me) banal differences between
researchers and practitioners.

Yes. Since research and business has different goals, then
they do things differently. And it is not specific for
design patterns or software development in general.

Arne

 

[Jan Paulsen]

Yes. Since research and business has different goals, then
they do things differently. And it is not specific for
design patterns or software development in general.

Arne

Yep, that's it, thanks.

Regards,
Jan Paulsen

 

[Jan Paulsen]

That's what I was hoping. Loved Papadimitrou, but it's been a while.
Reference, please? Someone?

Regards,
Jan Paulsen

Would it be regarded bad tone if I asked this guy by direct mail where I
could read more about that interesting definition?

Regards,
Jan Paulsen
(being completely off-topic, I know, please bear with me for this one)