> Beside that, basics of category theory is far easier to grok than OOP Design patterns.
I know high-school dropouts and graduates from DeVry University who understand design patterns. Category theory--even basic category theory--isn't taught to undergraduate math majors (except maybe at MIT to honors students).
I mean, I appreciate functional programmers who want to do it because it is hardcore... but that's why they do it: because it's hardcore.
> I appreciate functional programmers who want to do it because it is hardcore
That's a misconception. Functional programming makes so many things so much simpler. I know, Haskell can be seen as an impractical exercise for the sake of tickling your prefrontal cortex. But again: there are other functional languages, e.g.: Clojure - it is simple and allows you to get things done in a pragmatic, reasonable and relatively quick fashion.
Recursion is the worst way to do iteration because it requires cleverness (= harder to debug) and it's ridiculously easy to cause a stack overflow. A for-loop is not going to cause an integer overflow on a 64bit architecture.
Closures are basically global variables and inherit all of the problems with global variables.
Continuations are basically goto's or memcpy and inherit all of the problems with goto's and memcpy.
Functional programming is ALL of the bad programming practices of the '80s. But because it's more abstract and mathematical it gets a free pass. Nevermind the fact that computer science is not mathematics. And the benefits of mathematical abstraction DO NOT TRANSFER if they inherently violate the commandments of bad ideas like global variables and goto's.
There are solutions to ALL OF the object oriented problems--including the diamond problem, circle-ellipse problem, and overuse of type hierarchies. There are no solutions to the functional programming problems because they inherently incorporate bad ideas described in paragraphs 1, 2, & 3.
> Recursion is the worst way to do iteration because it requires cleverness
No, it doesn't; in fact, recursion is usually much easier to reason about, particularly in terms of termination.
> and it's ridiculously easy to cause a stack overflow.
It's ridiculously easy not to, just assure your recursive calls are in tail position and you are using a language that supports tail call optimization (which essentially every dedicated FP language and a number of others do.)
> Closures are basically global variables
No, they aren't even similar.
> Continuations are basically goto's
Not really. They are similar in that they are a more powerful (and, therefore, dangerous if used incorrectly) flow control concept than simple function calls, but they aren't equivalent to gotos.
> Functional programming is ALL of the bad programming practices of the '80s.
No, that's unstructured imperative programming (though some structured languages preserved some of them.)
Closures are as hard to reason about as global variables are. Anywhere the function with the closed variable is called, that is the same thing as invoking a global variable, because that function could be called anywhere in the entire program. The difference is that the garbage collector deletes it when no function is calling it any longer.
Continuations are equivalent to memcpy... which should almost never be used. And tail-optimized recursive functions are still difficult to reason about.
And tail-call optimization (making stack calls constant) is... kind of self-defeating... because the only advantage of recursion is that it has a stack built into the function call/return operations. Anything a recursive algorithm can do is equivalent just a for loop and a stack data structure. And if you're tail-call optimizing it so that it has a stack parameter... then you're just using a clever way to write a for-loop :D Except functional doesn't allow for you to mutate a preexisting stack so you're also wasting space recreating a new stack each function call.
Yeah. Abstract math almost rarely transfers directly to the computer world. There's a reason why the pure functional & concurrent language Erlang was only used in telecoms and languished in obscurity: because that was the only domain it worked well in.
Holy shit. You're into something here. Hey, you should immediately send letters to companies like Wallmart, Apple, AT&T, etc. most of them are in Fortune 500 list. They all use functional programming languages. You could save them billions!
Computer science uses a completely different system of logic than mathematics or mathematics-inspired paradigms like functional.
Fortune 500 companies aren't attracted to functional. They're attracted to the TYPE systems of many functional languages. And type systems are good. But you can build e.g. a dialect of C or Pascal using those exact same type systems with no functional programming at all.
Python tries to move away from functional idioms whenever the developers realize that the idiom can be severed from the paradigm. E.g. Python's switch from filter(list, p) to [x for x in list if p]. Guido van Rossum feels that the imperative way is easier to understand and so do I.
Functional programming languages have good ideas, like type systems or lazy evaluation. But many of these ideas are NOT INHERENT to the paradigm. Perl6 incorporates almost every functional programming idea but as an imperative language.
Now if you'll excuse me once I complete my Ph.D. dissertation I might be able to finish my text editor I'm programming in Haskell.