Functional programming versus patterns

I haven't worked with a functional programming language since college, where LISP was big; I haven't touched Ruby or the C# 3.0 preview as of yet. Today I learned a couple of fascinating things about them: functional programs inherently support concurrent execution (Hejlsberg articulates this); and -- more of a "wow!" for me -- functional languages don't need no stinking design patterns:

In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together. Once such pattern is an Adapter pattern (how is it different from Facade again? Sounds like somebody needed to fill more pages to satisfy their contract). It is eliminated once a language supports a technique called currying.

I admit appreciating the dig at the pretentious and unreadable Gang of Four. But the important point is this: although we software engineers think of them as these happy helpful things, the very utility of design patterns reflects the inherent impedance between (imperative) programming and the software solutions we want to build. There is tremendous conceptual baggage involved in implementing a working system, and much of that baggage is necessitated by our implementation paradigms.

Now, whether or not this doesn't have to be the case, and functional programming's poop doesn't smell, as coffeemug at defmacro.org is implying, I don't know.