What Is The Difference Betweena Pattern And An Insight

Q1: What is the difference between a pattern and an insight?

A1: A pattern is an insight that has survived reality at least three times. In effect, it's an insight that proved valuable beyond its original application.

A2: A pattern is a solution to a problem, an insight may not be. E.g. GotoConsideredHarmful is an insight, but it is not a problem.

A3: A pattern is a "characteristic of a good example". A property to bother preserving. An insight isn't anything like that. --AlistairCockburn

A4: You guys are all off in the weeds. The difference between a pattern and an insight is you can use a pattern to make the same dress over and over. Try doing that with an insight. -- WaldenMathews

Some addtional differences:

 An insight is useful by the perceiver, A pattern is useful by the adopter.
 An insight is a perception, A pattern is a notation.
 An insight is an "I see a way", A pattern is a "Do it this way"

Hmm. "GotoConsideredHarmful" does seem to be a pattern. In reading the original paper we see that it says that the perceived problem is that of poor code, and that the lack of quality is strongly correlated with the use of GOTO. That can be cast as a pattern, surely?

However, perhaps your point is valid and your example poor. I would appreciate further expansion of each definition to show how each precludes the other, or that one is a special case of the other.

For example:

Insight: An observation that allows us to solve a particular problem or understand a situation.
Pattern: An insight that allows us to avoid or solve a perceived problem and which is applicable beyond its original context.

Q2: OK, an insight can be used to understand a situation, however this aspect does not show up in the definition of Pattern. Could we expand the defnintion of pattern to include a way of understanding a situation applicable beyond its original context.

AnswerMe

Q3: Can an insight be weighted toward 'how to create something' rather than on allowing us to solve a problem?

I'm not sure GotoConsideredHarmful is a pattern. I'd be interested to see it described using the AntiPatternTemplate.

Surely, it's Using Gotos that is the pattern, thus:

Problem: how do I create loops in my code, and have bits conditionally executed?

Solution: use gotos

Up until EwDijkstra's paper, the general consensus was that this was a good solution, a (positive) pattern. Dijkstra's insight was that it was in fact a bad solution, hence an AntiPattern - StephenHutchinson

I think you'll find that until that paper it wasn't considered a problem or solution - it just was. By that reasoning we have a problem (poor code) and and insight (it's related to GOTOs). Then the solution is AvoidGoto?. That seems to be a pattern.

Well, at some stage in the evolution of computers with a VonNeumannArchitecture, somebody solved the problem of how to create loops and conditional code by inventing the conditional branch instruction, which evolved into the goto statement. By the time Dijkstra wrote his paper this was considered to be such an 'obvious' solution that it was, well, just the way things were done. Dijkstra saw that the solution also created a serious problem: bad code comprehensibility. I.e. that it was an AntiPattern. (Perhaps that's a bit strong. The problems that goto causes are not as bad as the problem is solves)

The refactored solution was not AvoidGoto?, which tells you nothing (you might just as well say that the solution to Burglary is Avoid Burglary). The refactored solution was StructuredProgramming, another pattern which solved the same problem but without the bad effects of goto. - StephenHutchinson