My problem with Design Patterns, (the book rather than the underlying concept) is that it attempts to do for programming what 'painting-by-numbers' does for art. And from my experience, the former 'succeeds' to almost exactly the same extent as does the latter.

That's not to say that individuals cannot read the book and draw very useful lessons from it. They can and do. But it's my contention that those same individuals would have quickly started to recognise recurrent themes in the code they write, read and maintain. Without the silly names, or falling into the trap of fill-in-the-blanks development practices.

The problem is that far too many CS teachers rely solely on teaching "the patterns"; and so we have a whole generation of programmers that have never been taught the processes and skills of analysis. And so you end up with a high proportion of those that learnt their programming in this way, that never actually look for the patterns.

They simply write every program in terms of the "top eight patterns"--Abstract Factory; Adapter; Composite; Decorator; Factory Method; Observer; Strategy; Template Method et al. Because, after all, the book said:

It's hard to find an object-oriented system that doesn't use at least a couple of these patterns, and large systems use nearly all of them.This subset will help you understand design patterns in particular and good object-oriented design in general

And so, it became a self-fulfilling prophecy. If you doubt this, just wander over to CPAN and search for all the modules and suites that contain a "*::Factory::*" element. (Or three). And then take a look inside some of them and see how many of them will never be called to instantiate more than once in any given program. You don't need a factory to produce a single, bespoke item.

That might be seen as 'unfair', as it is very easy to confuse the purpose of a 'Factory'--which is meant to instantiate different (sub)classes--with that of a 'class' who's job is to instantiate instances of that class. But you'll see many of the other 'top eight' misused in similar ways. Because the programmers are taught the 'rules' without being taught when to apply them. The patterns, without the analysis skills to differentiate between a pattern and a meta-pattern.

Hence, you'll also see the Decorator used to add a single attribute to a class, when a simple subclass would be appropriate. Or two copies of the Observer pattern used to implement bi-directional communications.

Recognising patterns is good. Implementing patterns because that's what you've been told you should be doing, is bad.

In the same way, threads, forks, selects deal with implementation. People are searching for an abstraction which simplifies away the complications and allows a higher level of comprehension.

I agree. That is what people are looking for. The problem is, you almost always do them a disservice by supplying it.

Every one of Perl's looping constructs can be implemented using redo (and one or two variables). But if every one dropped for/foreach/while/until/map/grep et al. in favour if redo, their code would be a nightmare to read and maintain.

Programming is a complex process. Perhaps as, if not more, complex than any other single occupation. There is a point below which it is not productive or useful to simplify or encapsulate further. It becomes a self-defeating exercise to try and wrap over every basic mechanism, or combination of basic mechanisms, with a higher-level abstraction.

At each higher level of abstraction you either loose the possibility of control over the finer details; or you end up with an api that attempts to encapsulate all the exponential combinations of parameters to all the low-level constructs being encapsulated. And you either get monster APis; or monster suites of interdependent wrap-over modules; Or both.

By inverting the flow of control, and generalising the interface for the 'poster child' typical case, you end up creating a far steeper, and broader and deeper, learning curve tree than that, that you set out to reduce. And along the way, you discard the flexibility to use simple, appropriate solutions as the need arises.

Far better methinks, to say that there are some, somewhat difficult, basic concepts that you need to just knuckle down and learn. Because once they've clicked, you'll rapidly assimilate them in a way that means you'll have a full toolkit at your disposal when it comes to solving real-world coding problems. And your efforts will be rewarded over and over.

I think good design shows. There's only one DBI; one LWP; one IO::Socket, one List::Util. And one threads. But half a dozen dumpers; half a dozen Find::*; half a dozen *event* thingies.

And I think the quality of a module's design shows in the number times people can offer, of-the-cuff, working code solutions to OPs problems, written in terms of those modules.

If you want my measure of CPAN module's "Kwality" [sic], there it is in a nutshell. When I see advocacy through demonstration rather than referral; I see something worthy of investigation.