[kuzux]

First of all, ActiveRecord is not a GoF pattern and its intent is not trying to implement the lacking dynamic features in static languages. Thus, it's not trivial or a source of unneeded complexity in ruby. And so is MVC(Actually, MVC is quite different from the other "Design Patterns" as it covers the entire architecture of the system instead of just a part of it).

The point is, most GoF patterns(like factory, builder, strategy, facade etc.) are trivial in "dynamic" languages like ruby and lisp and strictly applying those static-language-origin patterns cause nothing but unneeded complexity in ruby.

[sha90]

I never claimed Active Record was a GoF pattern, in fact, I'm sure it would be easy to read that I cited "Martin Fowler". Whether or not it's GoF, Fowler or any other source doesn't change that it's a design pattern, though. GoF patterns are no different from Fowler's EAA patterns. One is not meant for static languages while the other is meant for dynamic. That's not how patterns work. If you think that GoF patterns were specifically made for Java, you should look at the publishing date of the book. You might also consider that the book uses Smalltalk in its examples. PS. Smalltalk is dynamic.

The problem with your argument is that the "triviality" of their implementation has nothing to do with whether or not you use them.

    class X < DelegateClass(String); end

This is using the delegate pattern. It's pretty damn trivial to implement. But we are using the delegate pattern. This is a fact. We can do the same for singletons, factories, facades, visitors and strategies. How you implement them does not define whether or not you use them. Whether or not you tell people you use them is what matters, because patterns are about communication, not implementation. If you don't understand this simple concept then you're completely missing the point of design patterns.

Yes, you can implement the Adapter pattern in Ruby without doing anything explicit-- that doesn't mean you didn't use the Adapter pattern. This is where denial kicks in. If you say "I don't use strategy patterns, I use DYNAMIC PROGRAMMING!" you're seriously deluding yourself.

[tptacek]

You're playing semantic games. If we accept your terms, we're adopting the GoF patterns any time we use "method_missing". You're also arguing with a straw man.

The original idea behind the "Design Patterns movement" was to provide a common language for describing recurring concepts in software design. It's the same idea behind Alexander's "A Pattern Language", which is something else you should read.

Nobody is arguing that describing things a little more rigorously is bad. But a lot of people have problems with the way "engineers" and "architects" abuse the pattern concept.

Alexander did not write a book that claimed you could build an entire city by picking out a "44. Local Town Hall" and mixing it with a "69. Public Outdoor Room". He had an idea, that the cart was dragging the horse in architecture, and attempted to use vocabulary to reframe the discussion about why specific choices were being made.

The Gang of Four introduced a minor corruption in that approach --- they had no fundamental thesis about how software should be designed, only a notion that there was folkloric knowledge that should be captured and named --- but their followers completed the corruption wholeheartedly. Instead of a language describing software, the GoF patterns became a perscription for building it.

And so we have Ruby code that includes a "singleton" module into classes, and SOAP4R code that includes "factory" classes (note again how ruby already transparently supports the abstract factory concept), and people argung that we should start "doing a little engineering" by pulling these clumsy ideas back off the shelf.

I can't argue this any better than Norvig can. In fact, I'll invoke him again by suggesting that you don't want to end up like Norvig's "opponent" in the sudoku-solving contet.

[mquander]

OK, but why would you ever want to say, for example, "I use the strategy pattern here to pass a sorting mechanism into this other function" instead of "I pass a sorting function into the other function?" What utility does it have to think of such a thing in terms of a "strategy pattern?"

In Java, I guess it makes sense to have a separate concept for such a thing, since you can't pass around a function or a function pointer, so you need some wrapper code and some extra architecture in order to do it. But in a normal language, who cares about the pattern?