For those of you interested in learning more about patterns in
general, there are a number of mailing lists available which discuss
patterns and pattern-related subjects. For a full list see
http://st-www.cs.uiuc.edu/users/patterns/
Lists.html
Here's a recent discussion from patterns- discussion regarding the publishing of "prototype" patterns. These are patterns which do not qualify under the so called "Rule of 3". The rule requires that, to be a pattern, it must have been used in 3 separate instances. Oh, and the "Ralph Johnson" who rounds it off is one of the notorious "Gang of 4".
If you're wondering what the "wiki" or "wiki wiki web" is I can only suggest you point your favourite web browser at http://c2.com/cgi/wiki?WelcomeVisitors . Follow the links and enter a new world of "interactive" web pages.
kderrick@cix.compulink.co.uk
I want to be a pattern miner. So far in my career, I have designed and written code that I know (in retrospect) has patterns - GoF and others. Some patterns may not even have been documented yet.
However, I probably can't dig up three separate uses for every "new" pattern I "discover", but I *do* want to go ahead and capture the constructs in pattern form and disseminate for comments. I want to know if I found gold or pyrite.
So how about this: we call these "unproven" things "Proto Patterns". That way, we can get them out there where other people can either provide supporting known uses, or a better/alternate pattern or proto-pattern. (see http://c2.com/cgi/wiki?ProtoPatterns )
DavidH@catmktg.com (David Hooker)
I like this idea Dave. Another issue is that we may know of successful uses of the pattern but be under nondisclosure or other secrecy constraints in revealing where these patterns are used. (As long as we know of more than one usage, revealing the common pattern they share shouldn't be construed as revealing anything secret. Then again, I'm no lawyer...)
jkotula@unimax.com (Jeff Kotula)
>So bow about this: we call these "unproven" things
>"Proto Patterns". That way, we can get them out
>there where
other people can either provide support
>ing known uses, or a
better/alternate pattern or
>proto-pattern.
I think it's a good idea. Requiring that someone have personal experience with three implementations of a pattern implies that they have many years of experience, probably 15 years or more. That's a big restriction for a field populated mostly with young people.
This addresses Dick Gabriel's earlier point that the literature of programming is very limited. We have little published code from which to draw examples. We need an organized way to share our personal experiences, since we generally can't publish our source code.
Wiki Web is one mechanism to support this. The Patterns mail list is another possibility. Are these good enough, or do we need other mechanisms?
tomg@vasci.com (Tom Groot)
It's not clear to me how big a restriction " 3 implementations" really is. It's not like the rule of three is universal. For example, the point behind the pattern stories web at UIUC is to share information about implementations of GoF patterns. At what point do implementation details become new patterns ? There's a sort of fuzzy cloud around the GoF patterns where "protopatterns" are forming and being talked about without the rule of 3 being invoked (since it's already been invoked for a related pattern).
As to protopattterns proper: might I suggest a different approach ? The idea of a protopattern jury, modeled after the humor oracle, seems reasonable.
The way the humor oracle works is this: You submit your question (for the oracle) to a mailing address. Your question gets popped on the end of a queue. When someone feels like being the oracle, she sends e-mail to a different address (or maybe it's the same address with a different header. It's been a while since I've read rec.humor.oracle). She gets a question e-mailed to her, which she then answers.
(sidenote: the whole thing is intended to be funny. Questions follow a fairly standard format, including obligatory grovelling, and are generally ridiculous. Responses involve a fair amount of blustering and invocations of oracular omniscience, followed by an even more ridiculous answer).
Would a similar thing for (proto)patterns be reasonable ? If we write one (proto)pattern every three months, but review ("answer the question" in the oracle analogy) every month, that gives the average (proto)pattern three shots at individual review and response before public revelation or private junking. And it allows the reviews to be at a greater depth than is, perhaps, possible on a mailing list or on wiki.
william@pdh. com
>It's not clear to me how big a restriction "3
>implementations" really is.
Well, suppose I find a particularly "cool" solution to a problem. Suppose it resolves the forces at play in my context. I might think that others could benefit from my insight, so I want to write it as a pattern. I might think that others have also found this "cool" solution, and therefore it *is* a pattern. I might think that someone has a better solution, which itself could be a candidate for a pattern. In any case, I want to write this up as a pattern, but *my solution is not "proven" by current standards*.
>It's not like the rule of three is universal. For
>example, the
point behind the pattern stories web at
>UTUC is to share
information about implement
>ations of GoF patterns. At what point
do
>implementation details become new patterns ?
>There's a sort
of fuzzy cloud around the GoF
>patterns where "protopatterns" are
forming and being
>talked about without the rule of 3 being invoked
>(since it's already been invoked for a related pattern).
I don't understand this. The GoF patterns all have Known Uses, and are proven. There are no protopatterns in Design Patterns. The Pattern Stories Web tells of more Known Uses of the GoF patterns. What I'm talking about are constructs that are *not patterns*... yet.
>As to protopattterns proper: might I suggest a
>different
approach ? The idea of a protopattem jury,
>modeled after the humor
oracle, seems reasonable.
>Would a similar thing for (proto)patterns
be
>reasonable ? If we write one (proto)pattern every
>three
months, but review ("answer the question" in
>the oracle analogy)
every month, that gives the
>average (proto)pattern three shots at
individual
>review and response before public revelation or
>private junking. And it allows the reviews to be at a
>greater
depth than is, perhaps, possible on a mailing
>list or on wiki.
This is just a method of distribution, like mail- lists and wiki. It sounds like a good one, to me. But I would not like to mandate any particular method of "pattern validation" before a pro-topattern was accepted as a real pattern. From what I can tell, if the pattern can cite at least 3 known uses, or prove long term success, then it "passes the Proven Practice" test.
DavidH@catmktg.com (David Hooker)
I was unclear. The point was this—accept GOF stuff as "patterns." Whatever such acceptance implies. Now the patterns have an associated set of implementations. Sentences of the form "This code is an instance of that pattern."
Some of the implementations begin to diverge. For example, on the pattern stories web, there is a discussion of whether a particular implementation is "really" memento (see http://st-www.cs.uiuc.edu/cgi-bin/wikic/wikic?PicklingAndEmbalming for details).
Either it's memento, or it's a closely related pattern, located in the fuzzy cloud around GoF patterns.
And so on. As we adapt GoF patterns to our contexts, we sometimes come up with substantially different things. Patterns which are close enough to GoF patterns to (at least, in my mind) have the rule of 3 waived (or downgraded to the rule of 2) and yet, are distinct from the big 23. ¦
>This is just a method of distribution, like maillists
>and wiki From what I can tell, if the
pattern can
>cite at least 3 known uses, or prove long term
>success, then it "passes the Proven Practice" test.
What I was aiming at was the idea of forming a basis for "peer review" and detailed feed-back. You send in a pattern. A set of three random (randomly chosen from the people interested in patterns) comment on it (and, if things go well, e-mail you to ask questions and suggest clarifications) send you e-mail over the next two months or so. The point of using the oracle system for attaching people to pro-topatterns is that you go outside your clique (it isn't always Bob down the hall, who thinks the way you do and works on the same project, who reviews your ideas). The point of doing it by personal e-mail is that I think greater depth can be achieved (and greater efficiency—the vetting will be done by three people, instead of being simultaneously done by 200). In effect, instead of requiring 15 years of experience on your part, we're requiring 5 years of experience from 4 people.
After modifications and discussions, the pro-topattern is ready. Either for a wiki page or for further thought.
william@pdh.com
I've been "listening" to the discussion about "I can't publish my pattern because I'm not old enough to have used it three times", and the like.
Let me suggest that "pattern mining" isn't quite the right term, because the things we mine have, in general, been in the ground for at least millions of years, and none of us want to wait that long to start mining patterns. :) So I'll suggest another metaphor and some terms.
We seem to be discussing two kinds of pattern acquisition—I'll call them "pattern farming" and "pattern logging", for reasons that will become clear.
If I'm a Pattern Farmer, I produce patterns from my own work. I think I have a pattern (a proto-pattern) and attempt to use it in different places—planting the pattern, if you will. In the course of using this proto-pattern it will change and develop. If it is useful in enough places, particularly if they are sufficiently different that the proto-pattern must be reimplemented, and not merely be copied or relinked. After a few seasons, a full-grown pattern may emerge.
Pattern farming is thus much like tree farming—the time from planting to harvest is several years, at least (think Christmas trees, not mighty oaks, for current pattern crops).
Notice that programming hasn't existed long enough for "mighty oak" patterns to mature yet. And wonder about what a "Giant Sequoia" pattern might be, a thousand years from now. (or a "bristlecone pine" pattern, in ten thousand—twisted and gnarled by the forces that shape it...)
In pattern logging (nee mining), on the other hand, one searches through existing pattern forests for choice specimens. They're not easy to spot, the best ones are almost always in the thickest part of the forest, obscured by lesser patterns. Even when you think you've found one, it can be very difficult to extract. ... But perhaps we should leave this metaphor before we get lost.
Fundamentally, it sounds as if we're "complaining" that it takes time to grow or find patterns. That's true. It does. On the other hand, we're lucky—there are a few pattern forests that have been around for 30 years or more. Here at Lucent Technologies, we've been building electronic switching systems since about 1960. I came in 1976 and began learning what we now call patterns in the existing systems I was modifying. We've reinvented the same solutions a number of times. Finally, we've a few people actively searching for patterns to help build new systems.
I don't know that we need to leave finding patterns to the "experts", as was suggested somewhat earlier. I suspect we simply need to recognize that it takes experience to have seen the "same thing" three or more times. That experience can come either from having done several development cycles, or from studying in sufficient detail the results for several development cycles.—That's the difference between pattern farming and pattern logging...
Publishing proto-patterns essentially distributes pattern seeds, so more of us can plant them— there may be a better chance for such a proto-pattern to mature, because there will be multiple plantings, but I doubt it will cause many of them to mature any more quickly...
Patience is a necessary virtue in pattern farming. C'est la vie.
jwdavison@lucent.com (joe davison)
>Some of the implementations begin to diverge. For
>example, on the pattern stories web, there is a
>discussion of
whether a particular implementation is
>"really" memento. Either
it's memento, or it's a
>closely related pattern, located in the
fuzzy cloud
>around GoF patterns.
Hmm... Regarding that discussion on Memento: I see no reason for the pattern to limit itself to resoring the *same object/instance* to the memento'd state. So to me, Brad used the pattern, not a "new one".
>And so on. As we adapt GoF patterns to our
>contexts, we
sometimes come up with substantially
>different things. Patterns
which are close enough to
>GoF patterns to (at least, in my mind)
have the rule
>of 3 waived (or downgraded to the rule of 2) and yet,
>are distinct from the big 23.
I think we are talking about 2 slightly different things. I call a "protopattern" a new, undocumented construct of [insert favorite pattern definiton here], which simply is lacking in Proven Practice. The "proto" part is really just a disclaimer from "proven-ness". A prototype-pattern.
However, if the pattern is really a mutation of a GoF (or any other) pattern, does this give it an aire of "proven-ness"? That's a good question. I believe that I read somewhere that a pattern that is based on proven patterns, satisfies the Proven Practice rule. Like Extended Observer, maybe?
>What I was aiming at was the idea of forming a
>basis for "peer review" ...
That is certainly a good way of finding other known uses. I believe that a publicy accessable forum should be used for this purpose. I just dont want to mandate a particular method (although I *really* like the oracle idea!)
>After modifications and discussions, the protopattern
>is
ready. Either for a wiki page or for further >thought.
Personally, I'd probably do all 3: pat-terns@cs.uiuc.edu, wiki, and the oracle.
DavidH@catmktg.com (David Hooker)
>Let me suggest that "pattern mining" isn't quite the
>right term, because
I really like that metaphor, except for one thing.
My interest in the protopattern is not just to quicken the maturity of the pattern, but also to identify it in the first place. If I find what I think may be a pattern, I'd like to let people know for 2 reasons: (1) maybe it already *is* a pattern (it is in use by others) and I just don't know that, or (2) it could be the "seed" for others to use (and thus help "prove").
Why should I wait and "farm" more known uses before I tell anyone? Proto-patterns are instances of "pattern logging" patterns with little "proven-ness", and a disclaimer. It could help get more Pattern Farmers in on the job! Three plants grown in parallel by three farmers show three instances faster than three plants grown in succession by a single farmer. In don't see any problem in this.
Oh, and I'm not "complaining" that it takes time to mine/develop patterns. I'm simply suggesting a way to share information (via pro-topatterns) so that people can work together (share experience) to provide a better product (a real pattern).
DavidH@catmktg.com (David Hooker)
>I don't know that we need to leave finding patterns
>to
the "experts", as was suggested somewhat earlier.
>I suspect we
simply need to recognize that it takes
>experience to have seen the
"same thing" three or
>more tunes. That experience can come either
from
>having done several development cycles, or from
>studying
in sufficient detail the results for several
>development
cycles.—That's the difference between
>pattern farming and pattern
logging...
Just a quick addition: looking for the solution to a problem and finding people telling you that something is "the obvious" solution" to a particular problem, since "we always do it that way.." is a hint about where to look for a pattern. This may not validate a pattern, but gives you a pretty good idea where to look. This might be particularly relevant when it comes to domain specific patterns.
berczuk@world.std.com (Steve Berczuk)
While I won't confine pattern mining/logging/finding to experts, I would say that it is clearly not something a novice can do with *only his own experience* to guide him.
If one is a novice, they rightfully have difficulty in contributing to an experience base. Obvious, eh? Luckily, that doesn't keep them from participating.
The advantage of new people is that they have fresh eyes, and might see things that 'inbred thinking' of the more experienced might have missed.
Pattern "finding" is (IMHO) inherently a collaborative effort. If you're trying to codify experience, isn't it best to combine the experience of many people?
The idea of finding a 'proto pattern' and publishing it informally for review is a very fine idea. It allows relative novices to get input from people with more experience. The sum of this experience along with the creative juices of a novice can be extremely valuable.
With the 'net and its related tech, we have the ability now to do what we could only have done slowly and with great difficulty.
tottinge@csci.csc.com (Tim Ottinger)
It is fine to publish proto patterns. The patterns@cs.uiuc.edu mailing list is for exactly that purpose. Even if you think you have three uses, you probably won't have the forces right at first, or you will have defined it too narrowly. Patterns need a lot of experience to get right, and the best way to get that experience is to have a dozen people think about it and compare it to their experience. The patterns list has been quiet lately, so I encourage all you pattern miners, farmers and loggers to use it!
