I guess you could argue that all the moronic OO voodoo theory books are trying to say this. I don't think so. I think he's a got a point.
It's not easy to develop things so useful & elegant that you win people over... but it's easier than arguing the Internet into submission from a mailing list.
Functional language helps a lot in building of side effect free code. But such code can be written even in pure assembler. I writing in such style in any language, including Bash.
Sometimes I need to refactor somebody else code. Code functionality remains exact same after refactoring. Things that changed are: better code clarity, better reusability, and better testability as part of reusability.
Unit tests creates additional contexts, in which main code can be used, thus they force to improve reusability of the code, thus code forced to make less or none side effects, thus programmer forced to rewrite code in functional style.
Use code convention to define which flags, registers, and memory areas, IO registers, etc. must be preserved by the called function. Just ignore any other changes.
1) Default to functional ideas: Variables are immutable, recursion is encouraged, etc; but you can get access to imperative code when needed (Call this the Algoritmically functional languages)
2) Functional is the norm: You can't write non-pure functions with side-effects at all. These are the Pure Functional languages.
I am leaning towards 1 more than 2 personally, but many people would disagree with me on that one. The question is: Do you want a usable program written in class 1 or 2? Because there is a hell of a difference between them and how you build software for the two classes.
Interesting class 1 projects, where you can get the source code, are: ejabberd, mldonkey, unison, harmony/boomerang, coq, twelf, isabelle, coccinelle, and mlton.
Interesting class 2 projects could be xmonad, darcs, and GHC.
Of these projects, some would be easily implementible in imperative languages, some would be hard but doable and some would be insanely impossible to do. Please note that all things on the list are useful and elegant. But they might not have a user-base as big as other projects.
The closest thing I know is the website which became yahoo stores. It was originally written in lisp (no really functional, I know). The lisp worked great when they had a dedicated lisp manager managing it. When Yahoo took over, the rewrote it in something else, not because the something-else worked better but because they couldn't find/manage the development in lisp.
So functional might be failing this way. But it might just be hard to write big functional programming applications. I'd like to here more about this.
Hashlife algorithm might find some benefits from implementing it in a functional language.
You can program functionally in any language by eschewing side-effects whenever you can. Only that in some languages it is way easier to program functionally than others (ML, Scheme, Common Lisp, Erlang) and in some it is even forced (Haskell). The "idiot" here is the one that can't see or understand that it is easier to program functionally in functional languages and that it leads to better programs by doing so. To see this, you need knowledge of functional programming. And sadly, many people do not understand its finer points because they have not spent time writing non-trivial programs in functional languages.
If you know nothing about FP on the other hand, you could be lead into the concept of Dependency Injection, Design Patterns and whatnot, because your world is shaped around a statical subtyping system (In the case of Java). These concepts are not bad at all: they help Java programmers write better code (for most part) with fewer errors.