The "proof" is scattered all over the web, on blogs, forums and so on... most FP advocates have a bunch of utterly bad ideas:
You could probably have made a reasonable argument on some of those points, but you didn't. Let's see if we can pull any sense out of all of this. FWIW, I'm basically a dysfunctional programmer who's learning some FP tricks, but I still have some reservations about the crusading fervor and missionary zeal exhibited by some of the more fervent and zealous FP die-hards. (I nearly said "blowhards")
- "changing state is bad" - well, sorry, but computers are all about changing state... without changing state we can't do anything useful - their attempts to limit state change only result in crappy stuff, from highly inefficient code that uses tons of resources for trivial thing to stuff that doesn't work at all
Bad first example. It shows that you really don't know what you're talking about. This concept parallels most of the interesting ideas of OOP - encapsulation, for example, is based on the same principle. Why is the "principle of least privilege" important for oo programming? Same reason lisp passes states around rather than changing them.
Look forward to parallelism. How much effort goes into trying to manage threads in java? Why?
Turns out that if you don't allow state to be modified, that effort really isn't needed: you don't need to lock access to a process if you can't modify its state.
- "dynamic/inferred typing is good" - it's actually pretty bad, it leads to lots of bugs
Bad typing systems suck. However, Python, ML, and Scala all have reasonable typing systems that work nicely in FP. I have a conservative streak which makes me really appreciate the suspenders-plus-belt approach of Java (ArrayList<Foo> listOfFoo = new ArrayList<Foo> really doesn't bother me as much as some people think it should) but it's not the only way to work.
- "elegant, concise, terse, expressive code is good" - this is one of the most stupid arguments FP advocates often bring, without realizing that they're talking about extremely cryptic code in most cases (which is a very, very, very bad thing in real world software engineering), besides being a very subjective matter (as to what "elegant" means) ...
This happens in all languages. Go read some C, or some Perl.
- "commenting as little as possible is good" - this is more ore less related to their ideas about "elegant code" , "we spend out time thinking, not coding" etc. - awful, really awful stuff!
General agreement, across all of the languages I've worked in, is "if you're tempted to explain how it works, rewrite it so it's clearer". This goes along with "document functional units of the program, particularly wrt requirements and leave the rest" Again, not an FP issue.
I know, it's fun to come in and tell everyone that they're wrong, but it really doesn't seem like you've really spent any time understanding functional programming. There's plenty to complain about there, but this ain't really very convincing stuff.