Functionalism, aesthetics Was:(RE: I come to praise .join, not

[Carlos Ribeiro]

At 00:39 21/03/01 +0100, Alex wrote:
>Whatever holds in the realm of architecture, therefore,
>has no necessary parallel in that of programming, where
>"collective judgment" is concerned.

Humm. I've read dozen of answers, and got the impression that my point was 
somewhat misunderstood. That one summarizes best what the mistake is about. 
And please Alex, have some mercy when replying to me :-)

The parallel itself is valid, and we have a lot of theory on Design 
Patterns that say so. It's just that we are pointing our analysis to the 
wrong topic. Design patterns do not focus on specific solutions, but on the 
*substance* that is behind the solution. Analysing lots of solutions we can 
spot these patterns, and they say a lot about this "collective judgement" 
that is the net result of individual decisions.

We are not expecting collective judgment to make the right decisions. We 
have plenty of proof that this can lead to bad decisions many times. As a 
sidenote, this is one of the main failures of the "design-by-comitte" 
method. New things need to be invented by someone, and many times they go 
against what is considered to be the stablished way of doing things.

What we do expect is to collectively analyse the proposal using our 
knowledge of the past. Is this a sureproof method? No. Some of the 
innovative proposals will look nice at first but end up showing to be bad 
decisions. This is part of the risk of being innovative. The main point is 
that our collective judgement may spot failures. And sometimes, we do spot 
these failures by intuition. Is the intuition a valid tool? I believe so - 
sometimes we just feel that something is not right, and it takes an awful 
lot of time to find why. If we are analysing a problem where we do HAVE 
previous experience, we'd better checking what our intuition tells us.

Design patterns have other nice property. Good solutions just look right, 
because they fit nicely in some well defined pattern. Sometimes is pretty 
hard to do it, we try a lot of things, but end up finding by chance 
something that fits much better than any of the previous solutions.

Problem is, we cant just sit down and wait for ideas to pour over our head. 
We need to do something. And then we have proposals - lots of them - to be 
carefully considered. Some of them will fit the problem better than the 
others. It is actually desirable to try to develop ideas using some 
well-defined method, and the method itself can be described as a proven 
pattern. Programming techniques - structured, OOP, and so on - are full of 
design patterns that we keep applying to solve our programming needs. But 
the solution *must* fit nicely inside the problem, and our previous 
collective experience tells us a lot about that, sometimes just as a "gut 
feeling".

Many of the extensions that we are analysing right now follow well know 
patterns, many of them borrowed from other languages. Some of them are best 
described as "anti-patterns" - things that were done before, with dubious 
results.

For instance, why many of us are using Python right now? Because of the 
nice and consistent environment it does offer. I believe that the 
"featuritis" anti-pattern is going against it all. Well thought out 
features have their place (string methods, list comprehensions...) but I'm 
sure that some of the current candidates aren't really needed.


Carlos Ribeiro


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com