This is one answer to the problem raised by the article: certain things (like I/O) are less natural to do in a (purely) functional language, so a language which supports multiple paradigms can get the best of many worlds.

Another answer would be to have better language integration, so that it would be totally trivial to, say, write the purely functional pieces of a system in Haskell, and hook them up to I/O code in an imperative language, a GUI in an object-oriented language, whatever. That way, the implementors of a given language could focus on supporting a single set of strengths, without having to provide foreign-feeling or half-assed devices for doing things that aren't natural to do in that language.

Of course, this is an extremely difficult problem to solve, at least after-the-fact: once you have two languages that were designed without a specific plan for semantic integration with others, just passing simple data types between them can involve intractable difficulties. Thus, platforms which provide a common "metalanguage" are needed to make language integration more tractable. My impression is that we are seeing such platforms grow in both popularity and sophistication (e.g., the JVM), and accordingly seeing a rise in the popularity of languages that focus on a single paradigm but provide easy (or easier) integration with other languages on the same platform.

Really? When did they add pattern matching, algebraic data types, and reliable tail call elimination?

Reality is that imperative languages provide about as much support for functional programming as functional languages have for imperative programming: just enough to get by. And I would even say this is a good thing (perhaps excluding lisp: it can do everything due to sheer elegance rather than due to bloat).

I didn't say all features. In fact I said "has many, if not most". I was trying to be explicit that not all features that exist in every functional language exist.

Now with that said, the specific features you list, while popular, weren't widely considered "necessary" features to be classified as a functional language. For example, Scheme has neither pattern matching nor ADTs. Although I'll grant you that for modern functional languages its near a prerequisite. And AFAIK tail call elimination is less a function of the language, and more of the implementation (and I'd argue to the extent that you write in a functional style, many/most production quality compilers of imperative languages will do this optimization). Of course I could be wrong and maybe some functional languages define in their spec exactly when tail call elimination must invoked.

If you look at what is commonly the crux of functional languages you'll see things like:

* Recursion -- yes, there was a time imperative languages didn't support recursion. So when they were arguing Lisp vs Fortran this was relevant. Now this seems like such a passe feature of all languages, but I think its worth point out.

* First class functions.

* Lambdas and closures

* Immutable data

* Pure functions

* ADTs or other interesting type systems

And there are some second order features like list comprehensions.

Again, I think if you go through this list, you'll see that modern imperative languages capture a lot of these features. Not necessarily all of them, but I have discovered that I've been able to do some relatively straightforward ports of functional algorithms, keeping all of the functionalism intact.

Scheme does. I believe it was widely considered an innovation in the field of programming language specification that they specified that.