The problem the author finds with pure functional programming is very well known and is one reason people never use a pure functional language, sticking instead

The problem the author finds with pure functional programming is very well known and is one reason people never use a pure functional language, sticking instead to practical functional languages such as Erlang (that has processes), ML dialects (that have references), Haskell (that has IORefs and unsafePerformIO), Scheme and Common Lisp (that have full support for imperative programming), Clojure (that has Vars, Refs, Agents and Atoms), etc. I think the culture surrounding each of those languages does look down on using the mutation features (and for good reasons), but it's not like the message is "never use them", but rather "don't use them if you don't have to". Maybe the fact that he doesn't emphasize that his gripe is with pure functional programming and calls it plain "functional programming" is a little misleading.