Why patterns don't suck 
Author Message
 Why patterns don't suck


wrote in two separate messages:

Quote:
> One head-banger for some of you is a brief expose' on why patterns suck.

> -------------Patterns Exposed-----------------

> Notice these class documentation values do not (and hopefully will
> not) include "Patterns."  That is because patterns are not specific
> algorithms nor helpful documentation.  Patterns are just unnecessary
> style suggestions which are better left to an integrated methodology
> like Extreme Programming or a company style manual.

> [snip]

> Many people were fooled by the snake-oil of the patterns paradigm
> because "patterns" sounds important like "objects" and the books of
> patterns were far easier to write than tested algorithms so quite a
> few were written.  

Your expos may be valid for your understanding of patterns, but that
understanding is questionable.  Regardless of what the masses eager to
swallow the latest fad might have been thinking (I do not conduct surveys
so I have no idea if "many people" were indeed fooled the way you say), I
doubt that anyone who uses patterns for the value *they* found in them ever
looked at patterns this way.  Nobody in their right mind I spoke with
thought of them as the replacement of algorithms or documentations.  They
are not "style suggestions" either.  

Patterns are optimal solutions to commonly occurring problems.  The first
mistake to make after reading that is to say, "alright, so I need a
cookbook with a few hundred--no, better a few thousand of those babies and
I am ready to roll as an OO programmer".  Perhaps this mistake has been
made, at least judging by the fervor of some to catalog thousands of
patterns supposedly out there, or Netscape's contest a few years ago to
"discover patterns" in Netscape source code.  This is utter nonsence, of
course.

Patterns are examples of good solutions, but they are not "instant
experience" conveniently packaged for you ready to be used.  They are the
guides for cultivating your own thinking, intuition and the sense of what's
right and what's not.  They will guide you, but it is *you* who has to grow
to benefit from that guidance.

Certainly, this second perspective is much less attractive, and even alien
to this industrial culture.  How can there be things that cannot be
purchased for the price of a book or the cost of a training course?  What
do you mean an employee cannot just read a book and become qualified to do
a job?  [OK, I won't go there further...]

I don't know if patterns really were hyped the way you imply, though the
above assumes that it is likely.  Even so, what does it change?  People get
fooled all the time, and always for the same reason: they want to believe
in miracles.  A revolutionary programming paradigm that can replace what's
supposed to be between one's ears is just another form of an ancient secret
ointment supposed to make one smarter.  When hype dies down and everything
comes into perspective, pendulum often swings the other way and "X
explained" all of a sudden is out, and "X exposed" is in.  But if you think
about it, such "anti-hype" is not any more valid or constructive than the
original hype was.

It is a pattern, you see. :)

--
Vassili Bykov [|] vassili "at" parcplace "dot" com
VisualWorks Engineering, Tools Technical Lead
[:s | s, s printString] value: '[:s | s, s printString] value: '



Thu, 05 May 2005 04:43:40 GMT  
 Why patterns don't suck


Quote:
>> They are not "style suggestions" either.
>> Patterns are optimal solutions to commonly occurring problems.

> [...] Show me an
> optimal solution to a problem and I'll show you an algorithm, not a
> pattern.

I was not talking about optimal in the sense of computation, as you could
see from my further description of the value of patterns.  Computation is
indeed what algorithms are about, and I do not dismiss or belittle their
importance.  I simply allow the existence of a second dimension in
programs, one that it not algorithmical.  It is program organization, or if
you will program beauty.  Of two algorithmically identical solutions, one
can be ugly and another beautiful.  Of three Smalltalkers technically
equally competent to solve a problem, one might be able to build a
beautiful solution, another might not, and the third might not even see the
difference.  Patterns can help one cultivate this feel for what's good and
what's ugly.

You are making a valid argument how patterns cannot replace algorithms or
documentation, and I never said anything against that.  (That was why I
called Netscape's contest nonsense).  If I have to distill my post, what I
wanted to say was that the argument "patterns cannot replace algorithms
therefore they suck" would only be valid *if* they were indeed supposed
to--when in fact those who thought so missed the point of what patterns are
about in the first place.

--
Vassili Bykov [|] vassili "at" parcplace "dot" com
VisualWorks Engineering, Tools Technical Lead
[:s | s, s printString] value: '[:s | s, s printString] value: '



Fri, 06 May 2005 10:26:24 GMT  
 Why patterns don't suck
Hmmm.

In a broad sense, I view patterns as being (opinion):

A description of principles and issues for an idea or process by which a
computational-solution can be structured/designed.

They capture and express principles. So one can say that given the following
scenario, with the following constraints, what "pattern" of
implementation/design would one consider? What are some of the pitfalls and
benefits one should think about when considering such a "pattern"?

They are more like an expert system summarization. Where given: some set of
goals, some set of constraints, one can quickly identify a solution
"pattern". The "pattern" does not provide the algorithmic computational
implementation. It discusses the data-structure relationships and issues of
collaboration and interaction, coupling, and all the other tradeoffs that go
into choosing/designing a particular computational implementation.

There are common patterns for many scenarios because the scenarios
themselves have common issues/principles. In one sense you can think of
patterns as being a way to organize computational principles based on
learned/acquired experience. I.e., we've seen this "pattern" of
characteristics before and we learned from investigating it that the
following "aspects" of that "pattern" were important to consider in
designing/choosing the particular characteristics of the computational
implementation.

Thinking in terms of patterns allows one to methodically find synergies,
simplify designs, unify infrastructure, reduce complexity, re-use principles
in complex scenarios, etc. Thinking in patterns is a natural human-brain
process for learning. For software developers it facilitates the ability to
apply consistent treatment to frameworks and implementation designs. Which
in turn makes frameworks and other designs easier to understand and easier
to evolve with some validatable confidence as to their robustness.

I think the "pattern" book craze was a bit nutty [and there was clearly some
exploitational practices as there have been in most of the software fads]. I
was certainly into thinking about patterns in software decades before the
architectural-pattern/book fad began. The evolution of the fad does not
diminish the value of identifying patterns, and it does not diminish the
value of pattern books in defining a common vocabularly that details some
common patterns/idioms fairly thoroughly.

I will say, however, that I have observed that many of the patterns that are
published are tainted by the languages in which the authors anticipated the
patterns being applied.

Personally, I think the value of thinking about software in terms of
patterns is really a question of how you expect to evolve your own skillsets
for software design.

You don't need any of the pattern books for this. But, reading them may help
establish or improve your skills. It may give you common vocabularly with
which to talk with others about software designs at a higher "semantic"
level.

However, probably most important is simply your own ability to look at a
problem and decompose it rapidly into a set of patterns in your own head, so
that you can subsequently compose solutions. And, when encountering
unfamiliar territory it is the skill to identify/define/discover the
patterns and the rules relating to them.

In many cases the patterns will help to identify [and document] the higher
level constraints, collaboration issues, tradeoffs, etc. Thinking in
patterns is an integral part of good design discipline/skills and it is
closely related to thinking about contracts and collaboration issues within
systems and components.

-- Dave S. [www.smallscript.org]


Quote:


> >> They are not "style suggestions" either.
> >> Patterns are optimal solutions to commonly occurring problems.

> > [...] Show me an
> > optimal solution to a problem and I'll show you an algorithm, not a
> > pattern.

> I was not talking about optimal in the sense of computation, as you could
> see from my further description of the value of patterns.  Computation is
> indeed what algorithms are about, and I do not dismiss or belittle their
> importance.  I simply allow the existence of a second dimension in
> programs, one that it not algorithmical.  It is program organization, or
if
> you will program beauty.  Of two algorithmically identical solutions, one
> can be ugly and another beautiful.  Of three Smalltalkers technically
> equally competent to solve a problem, one might be able to build a
> beautiful solution, another might not, and the third might not even see
the
> difference.  Patterns can help one cultivate this feel for what's good and
> what's ugly.

> You are making a valid argument how patterns cannot replace algorithms or
> documentation, and I never said anything against that.  (That was why I
> called Netscape's contest nonsense).  If I have to distill my post, what I
> wanted to say was that the argument "patterns cannot replace algorithms
> therefore they suck" would only be valid *if* they were indeed supposed
> to--when in fact those who thought so missed the point of what patterns
are
> about in the first place.

> --
> Vassili Bykov [|] vassili "at" parcplace "dot" com
> VisualWorks Engineering, Tools Technical Lead
> [:s | s, s printString] value: '[:s | s, s printString] value: '



Fri, 06 May 2005 10:59:47 GMT  
 Why patterns don't suck

Quote:
> Hmmm.

> In a broad sense, I view patterns as being (opinion):

> A description of principles and issues for an idea or process by which a
> computational-solution can be structured/designed.

I should have added that I believe patterns are part of the human solution
to managing complexity in software design.

-- Dave S. [www.smallscript.org]

Quote:

> They capture and express principles. So one can say that given the
following
> scenario, with the following constraints, what "pattern" of
> implementation/design would one consider? What are some of the pitfalls
and
> benefits one should think about when considering such a "pattern"?

> They are more like an expert system summarization. Where given: some set
of
> goals, some set of constraints, one can quickly identify a solution
> "pattern". The "pattern" does not provide the algorithmic computational
> implementation. It discusses the data-structure relationships and issues
of
> collaboration and interaction, coupling, and all the other tradeoffs that
go
> into choosing/designing a particular computational implementation.

> There are common patterns for many scenarios because the scenarios
> themselves have common issues/principles. In one sense you can think of
> patterns as being a way to organize computational principles based on
> learned/acquired experience. I.e., we've seen this "pattern" of
> characteristics before and we learned from investigating it that the
> following "aspects" of that "pattern" were important to consider in
> designing/choosing the particular characteristics of the computational
> implementation.

> Thinking in terms of patterns allows one to methodically find synergies,
> simplify designs, unify infrastructure, reduce complexity, re-use
principles
> in complex scenarios, etc. Thinking in patterns is a natural human-brain
> process for learning. For software developers it facilitates the ability
to
> apply consistent treatment to frameworks and implementation designs. Which
> in turn makes frameworks and other designs easier to understand and easier
> to evolve with some validatable confidence as to their robustness.

> I think the "pattern" book craze was a bit nutty [and there was clearly
some
> exploitational practices as there have been in most of the software fads].
I
> was certainly into thinking about patterns in software decades before the
> architectural-pattern/book fad began. The evolution of the fad does not
> diminish the value of identifying patterns, and it does not diminish the
> value of pattern books in defining a common vocabularly that details some
> common patterns/idioms fairly thoroughly.

> I will say, however, that I have observed that many of the patterns that
are
> published are tainted by the languages in which the authors anticipated
the
> patterns being applied.

> Personally, I think the value of thinking about software in terms of
> patterns is really a question of how you expect to evolve your own
skillsets
> for software design.

> You don't need any of the pattern books for this. But, reading them may
help
> establish or improve your skills. It may give you common vocabularly with
> which to talk with others about software designs at a higher "semantic"
> level.

> However, probably most important is simply your own ability to look at a
> problem and decompose it rapidly into a set of patterns in your own head,
so
> that you can subsequently compose solutions. And, when encountering
> unfamiliar territory it is the skill to identify/define/discover the
> patterns and the rules relating to them.

> In many cases the patterns will help to identify [and document] the higher
> level constraints, collaboration issues, tradeoffs, etc. Thinking in
> patterns is an integral part of good design discipline/skills and it is
> closely related to thinking about contracts and collaboration issues
within
> systems and components.

> -- Dave S. [www.smallscript.org]


message



> > >> They are not "style suggestions" either.
> > >> Patterns are optimal solutions to commonly occurring problems.

> > > [...] Show me an
> > > optimal solution to a problem and I'll show you an algorithm, not a
> > > pattern.

> > I was not talking about optimal in the sense of computation, as you
could
> > see from my further description of the value of patterns.  Computation
is
> > indeed what algorithms are about, and I do not dismiss or belittle their
> > importance.  I simply allow the existence of a second dimension in
> > programs, one that it not algorithmical.  It is program organization, or
> if
> > you will program beauty.  Of two algorithmically identical solutions,
one
> > can be ugly and another beautiful.  Of three Smalltalkers technically
> > equally competent to solve a problem, one might be able to build a
> > beautiful solution, another might not, and the third might not even see
> the
> > difference.  Patterns can help one cultivate this feel for what's good
and
> > what's ugly.

> > You are making a valid argument how patterns cannot replace algorithms
or
> > documentation, and I never said anything against that.  (That was why I
> > called Netscape's contest nonsense).  If I have to distill my post, what
I
> > wanted to say was that the argument "patterns cannot replace algorithms
> > therefore they suck" would only be valid *if* they were indeed supposed
> > to--when in fact those who thought so missed the point of what patterns
> are
> > about in the first place.

> > --
> > Vassili Bykov [|] vassili "at" parcplace "dot" com
> > VisualWorks Engineering, Tools Technical Lead
> > [:s | s, s printString] value: '[:s | s, s printString] value: '



Fri, 06 May 2005 11:07:14 GMT  
 Why patterns don't suck


Wed, 18 Jun 1902 08:00:00 GMT  
 Why patterns don't suck


Quote:
> I won't argue with that evaluation of patterns.  I am not sure which
> definition of beauty (since beauty is in the eye of the beholder) is
> actually helpful in getting more work done faster -- if beauty,
> elegance, or style helps at all.  

Yes, I was a little afraid to bring beauty into this.  But, it does not
have to be that subjective or vague after all.  It is the kind of beauty
you find in the Golden Gate bridge, a racing yacht, a grain silo, or an
airplane.  Form governed by function.  With software, this is less
apparent to an outsider, but aren't there designs that feel the same--
streamlined, light, clean and efficient--and others more like something
out of The Incredible Machine?  Certainly, the former kind is likely to
be better pragmatically as well.

Sure, there is not a lot of engineering yet in "software engineering".  
Often it's more like hunter-gatherers digging a pit with pointy sticks,
hoping to be done before the next mammoth comes down the road.  OK, maybe
with Smalltalk it's flint knives instead of pointy sticks. <g> Still, all
of those are bits of engineering with their place in the whole picture:
the algorithm of catching things in pits, the paradigm of using objects
to dig instead of bare hands, and best practice pattern of choosing a
spot where the earth is softer.  

--
Vassili Bykov [|] vassili "at" parcplace "dot" com
VisualWorks Engineering, Tools Technical Lead
[:s | s, s printString] value: '[:s | s, s printString] value: '



Fri, 06 May 2005 12:43:09 GMT  
 Why patterns don't suck


Wed, 18 Jun 1902 08:00:00 GMT  
 Why patterns don't suck
Patterns are created by people. People make mistakes.
Patterns is a structured knowledge that, if not understood correctly, can
cause more harm than usefulness.
In order for one to understand patterns, one has to follow certain patterns
to be able to get around...
Software development is an art, where a real experience can never be
replaced by patterns.

 Vlastik



Fri, 06 May 2005 14:47:40 GMT  
 Why patterns don't suck


Wed, 18 Jun 1902 08:00:00 GMT  
 Why patterns don't suck
To add one small observation to Vassili's comments...

It is common sense to say that beauty is subjective (i.e., in the eye
of the beholder), but under scrutiny this position proves to be very
difficult to defend. The problem is that beauty is neither subjective
nor objective. This may sound paradoxical, but that's one of the
reasons we have something called "aesthetics".  For details, see
Hume's "Of the Standard of Taste" and Kant's "Third Critique".

M



Fri, 06 May 2005 20:28:05 GMT  
 Why patterns don't suck


<snip>

Quote:
> So you have Emenem rap thumping your mirror askew from the vibes of your
> ride and it all makes sense as a poet who doesn't know it -- is that all
> there is, the vulgar explicitives or do you want your kid to learn
> derivatives and maybe the Bible and God to have a better touch with
reality
> and a better personality moving with a view toward absolute perfection?

So how does learning about the Bible and God get a kid to have a better
touch with reality ? Or a better personality, for that matter.
I would also be curious to find out more about absolute perfection. What is
it?


Sat, 07 May 2005 04:27:27 GMT  
 Why patterns don't suck

Quote:

> > >> They are not "style suggestions"

> Oh?  Read on.

> > I simply allow the existence of a second dimension in
> > programs, one that it not algorithmical.  It is program organization, or
>  if
> > you will program beauty.  Of two algorithmically identical solutions, one
> > can be ugly and another beautiful.  Of three Smalltalkers technically
> > equally competent to solve a problem, one might be able to build a
> > beautiful solution, another might not, and the third might not even see
>  the
> > difference.  Patterns can help one cultivate this feel for what's good and
> > what's ugly.

> I won't argue with that evaluation of patterns.  I am not sure which
> definition of beauty (since beauty is in the eye of the beholder) is
> actually helpful in getting more work done faster -- if beauty, elegance, or
> style helps at all.  I will admit there is a certian aesthetic pleasure
> obtained when a working solution also is a pretty solution.  But I am not
> certian the pursuit of beauty will be productive in a problem solving sense.
> Simplicity, flexability, usefullness, and readability may be a more
> productive pursuit.

My thumb rule for use of patterns, engineering methodologies is "First
build a simple verion of the application which provides the
required/known functionality with simple and readable code using
common sense(like putting responsibility at right places, giving
importance for encapsulation). Later refine it as you understand the
problem and dynamics of the application". If you try to think too much
about patterns/elegance upfront you just waste time or build wrong
solutions. As you build prototype you will better understand the
requirements and dynamics of the system. I am absolute believer in
spiral model of software engineering (which is followed by XP) against
simple water fall model with extensive deisgn/documentation effort
upfront(which is followed by RUP). All Smalltalk IDEs have used
patterns extensively(in fact software patterns almost originated from
there). ControlWorks (www.adventact.com) has used patterns extensively
to build software for semiconductor wafer processing machines. But
these are results of efforts for more than a decade by a large group
of people. I agree there are lot of benefits in using patterns. But I
have seen people wasting time to forsibly use patterns for almost
trivial solutions complicating very simple things (instead of writing
few lines of code in a method, they create dozen different classes,
scatter logic etc). Users can't wait for working applications forever
and in most application development environments, there is limit on
time and resources. Useability, functionality,reliablity, performance
take higher precedence over elegance (in the order mentioned, IMO).
Pragmitism overrides elegance. What matters ultimately is working
software and not inner elegance and documentation.


Sat, 07 May 2005 05:22:58 GMT  
 Why patterns don't suck
What about this alternative?



Quote:

> "Florin"  wrote

> > > So you have Emenem rap thumping your mirror askew from the vibes of
your
> > > ride and it all makes sense as a poet who doesn't know it -- is that
all
> > > there is, the vulgar explicitives or do you want your kid to learn
> > > derivatives and maybe the Bible and God to have a better touch with
> > reality
> > > and a better personality moving with a view toward absolute
perfection?

> > So how does learning about the Bible and God get a kid to have a better
> > touch with reality ? Or a better personality, for that matter.
> > I would also be curious to find out more about absolute perfection. What
> is
> > it?

> The word God is defined as absolute perfection. By definition, a
> personality moving toward absolute perfection is better than a personality
> moving toward absolute corruption aka. death (even if personalities
measured
> in a static mode are closer to the other state).

God is the convergence of several artifacts of the human brain's
implementation:

  1.. human mind works on much simplified and necessarily finite models of
the (for all practical purposes) infinite surrounding reality. The very
strong drive towards simplicity (and unified theories) leads us to abruptly
close the model with its complement (everything else). We call this
complement God.
  This (usually) reified model seems to be what fundamentally differentiates
us from other evolved animals

  2.. like other animals, humans also have lower-level, pre-wired
constructs. One of them seems to be the father figure: a higher authority,
something to be feared and revered, something that we try to emulate. Since
the concrete fathers are often absent or less adequate for their role as
model behaviors, human society has found it convenient to unify the two
concepts (1 and 2), thus making the father figure faultless, permanent and
always present, and therefore a more efficient educational tool
Perfection, on the other hand, means a very good, to the point of
non-improvability, level achieved in some useful or pleasant human activity
or artifact. Therefore the definition of God as absolute perfection merely
means absolute reverence.

Quote:
> All reality includes spiritual reality which humans contact through
> intution, conscience and communion/fellowship. To my knowledge, no one has
> yet published discovering a credible mechanical link to the spiritual
realm
> but there is ample scientific proof the realm exists. For example over 250
> NIH studies prove prayer works.

In other words, the currently accepted scientific model is incomplete. Quite
obvious.

Quote:
> Thus kids who pray are more connected to
> spiritual reality than those who don't.

Or one could say that they are more obedient, less inquisitive, less
independent

Quote:
> Absolute perfection can be viewed as a moving target -- for example, the
> more you know the more you know there is more to know -- except relative
to
> the Bible, God is defined as a being capable of knowing all, seeing all,
> being and acting in all things -- a being which has already arrived at
> absolute perfection which we can participate in by growing closer to God.

But, both for the definition of the ultimate goal and for the directions
towards this goal, we have to start by completely trusting other imperfect
people's imperfect words


Sat, 07 May 2005 09:09:11 GMT  
 Why patterns don't suck



Quote:

> > What about this alternative?

> An illogical waste of keystrokes so far, but maybe if you keep typing
> randomly eventually Shakespeare or something like it will be produced.

It definitely was wasted, at least on you.
By presenting an alternative to your certainties, I just wanted to remind
you that this is a multicultural as well as technical forum, so the only
appropriate evangelization here is about Smalltalk (even if that means
preaching to the choir).


Sat, 07 May 2005 11:18:39 GMT  
 Why patterns don't suck



|
| > I just wanted to remind
| > you that this is a multicultural as well as technical forum, so the only
| > appropriate evangelization here is about Smalltalk (even if that means
| > preaching to the choir).
|
| No bozo, the fraud of multiculturalizm has no valid place in the world,
| neither in this forum.  If the world were Christian, 9/11 definitely would
| never have happened.  The main use of all technical newsgroups is the
| pursuit of truth.  Your "alternatives" are obviouisly not truth, so it is
| your nonsense which is inappropriate.
|

Would you mind taking this conversation to private channels such as email
out of respect for those who are entitled to have their own opinions please?
Thank you.

-Boris



Sat, 07 May 2005 13:26:02 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Why 'C++' sucks++

2. Stipple patterns don't seem to work in arc and oval items on the canvas

3. why awk don't display the results?

4. Why I don't Like HTML Help...

5. Animated Gifs Some work some don't why

6. Why don't Memo Entry Fields wrap?????

7. I don't understand why my haskell program works

8. Why I don't use Dylan

9. Why collected languages don't need a free operation

10. Why don't large companies use Ada?

11. Why don't my textures map correctly?

 

 
Powered by phpBB® Forum Software