> Martin Fowler

What has this guy done except writing books about "the best way to program" without ever designing a full system himself ?

> Guido van Rossum, Yukihiro Matsumoto

Those guys are just language designers, and the language they designed are just as questionnable as the functional ones, so why do they get a pass actually ? Because their languages are more used ? Do you want to follow suit and say that COBOL creators are probably part of the "world's most experienced programmers" ? What about PHP ?

There are some good points and critiques about the practicality of functional languages, but you don't actually touch on any of them here.

There are lots of smart PL designers working systems languages, and there are lots of smart PL designers working on high-level, functional languages. That doesn't mean that either group is necessarily aware of everything the other group is doing, and it doesn't mean they share the same goals, experience, or taste.

To further answer your question, "functional programming" isn't always so well-defined. We know, realistically, that pure functional programming isn't going to work for all use cases. Once you're grounded in FP, you think of mutable state (or, in databases, destructive updates and deletes) as an optimization... but sometimes it's an optimization that you need. No language is FP-only because no language can be; even Haskell has the "dirty" IO monad.

I think that most good programmers (like, 99%) recognize the importance of immutability and referential transparency, when possible, and in the function rather than the action being the standard compositional unit for programs. Where there is disagreement is on when, how, and how often to depart from the functional ideal.

unsafePerformIO :: IO a -> a on the other hand does make haskell impure when it is used. And it is used in many libraries.

Hmm, does it really? Is 'unsafePerformIO (return 1)' impure?

Citation needed - or at least clarification as to what "many" means here.