"Design Patterns are the disease, Clojure is the cure..."

This is partly because lisps can act on their own expressions, transform them. This follows from extremely uniform or consistent grammar.

Now you could say C++ can do that, but look at the amount of machinery needed in Boost to add something like a lambda or an accumulator 'pattern' to the language.

Its a matter of degree - sure you can write a DSL in C++ [recursive descent, lex/yac, boost, macros etc] but in lisp this really is just a natural part of the language - syntactic sugar can be manufactured.

Lets take the idea of a callback - this is an excellent design pattern that gives you a great deal of power. You could implement using function pointers in C, or say functor objects with operator() in C++... either way, I contend there is a lot more crud and boilerplate than there is in lisp where a lambda is a fundamental construct of the language.

The more surrounding crud or machinery, the less clear the concept.

In other words, patterns in lisp can be _more_ clearly distinguished as such, because there is less cruft.

Often the name of the concept or pattern actually occurs in the code as a function name, for example.

The higher level abstraction aspects of a design pattern are usually better expressed without introducing codewords. E.g., the Observer pattern is just, "let's call a function on objects that want notification." It's the baggage that comes along with implementing these abstractions in blub that justifies a name as a pointer.

Related to the above, design patterns connote boilerplate; all that generic code that's needed to setup the pattern in blub.

I don't think Clojure is really a functional langauge, it's more of an imperitive/OO mix with immutable objects. Immutable objects aren't "functional programming", they're simply common sense.

Functional programming is about composing parts of programs ("functions") with generic combinators. I have not seen anyone in Clojure doing this. Haskell is a different story; combinators are very reusable, and there is no way to combine functions (and other "categories") without them. (In Clojure, you combine program fragments by typing a closing paren and then opening a new one. Your program doesn't control its sequence of operations, a Magical Runtime does that for you. Inflexible.)

The reusability in Haskell is quite interesting; for example, application in a monad is defined as "liftM2 ($)", the usual function application operator ("($)", itself a function of two arguments) lifted into a monadic context for functions of two arguments. Cool.

The reusability is everywhere; you use the same Arrow combinators to traverse an XML document as you do to parse plain text. (See HXT and PArrows.) And of course, you compose Arrows with (.) (the function composition function), because (.) works on all Categories, not just functions.

That is functional programming; Clojure is just immutable data and parens. (Both good ideas, mind you. But it's not doing anything that Pure Java can't.)

This is precisely why snark doesn't work. Snark isn't based on substantive analysis and argument. Instead, it's the same sort of stuff that had lots of us geeks ostracized in high school. It's the hipster/school clique side of human dominance and group-think instincts.

It's the reason why such inaccurate yet ineradicable notions continue to circulate in the programming field.

If one considers oneself a thoughtful computer programming expert, leave out the snark!