The author of this article appears never to have used a functional programming language in his life. He misunderstands several key terms in the realm of functio

The author of this article appears never to have used a functional programming language in his life. He misunderstands several key terms in the realm of functional programming and makes up a few of his own terms so that he can construct a strawman of what people claim functional programming is, which he can subsequently prove that it isn't. There are plenty of misconceptions about functional programming, but quite a bit more than combating them, he demonstrates how many he himself holds. > Myth #1 - Functional programming is Lambda Calculus Of course functional programming is not just lambda calculus—there are actual data types besides functions—but I don't think this is what he's arguing. He's trying to argue that “simultaneity” (which I think he made up) isn't satisfied, and somehow conflicts with lazy evaluation. This is only a valid argument about lazy, impure languages, and I don't think any exist. All of the differences he's claiming exist between lambda calculus and functional programming don't exist between lambda calculus and Haskell. > In point of fact, the simultaneity constraints inherent in lambda calculus have been shown to make it unsuitable for issues involving concurrency (like multithreading), and for problems like that, it's better to use pi-calculus. Whaaat?! Purely functional programming is much better suited to concurrency, because it completely satisfies “simultaneity constraints”, which makes race conditions, etc. impossible. > Myth #2 - Functional programming is 'different from' imperative programming. ... > Church's thesis, upon which we base our whole definition of 'computing', explicitly states that Turing machines, lambda calculus, while programs, Post systems, mu-recursive grammars, blah-de-blah-de-blah, are all equivalent. The entire point of the Church-Turing thesis is there can be completely different models of computation that can compute the same problems, not that they're all the same concepts underneath. > For those quick thinkers out there who've noticed that this puts Myth #2 in direct contradiction with Myth #1, KA-CHING! you've just won our grand prize! I'm not even sure what he means here. The statements that functional programming is based on lambda calculus, that it is different in significant ways from imperative programming, and that all models of computation can solve the same problems are not at odds in any way. > Myth #3 - Functional programming is referentially transparent This is where I get the impression that he has never actually used a functional programming language in his life, and he completely misunderstands what “referentialy transparent”. Haskell, barring its unsafe* functions, is indeed referentially transparent, which means that expressions will always have the same value no matter when they're evaluated. His use of Perl examples, using features of Perl that directly violate referential transparency, to demonstrate that functional languages aren't referentally transparent, is bizarre. > Myth #4 - Functional programming doesn't support variable assignment I don't even know what he's trying to prove in this section. Yes, functional programming does allow you to iterate functions on values to produce new values. Haskell's standard library provides several utility functions for doing just this. The point of not supporting assignment is eliminating mutable state, which results in referential trasnparency, and not letting the effect of one part of your code leak out in hard-to-predict ways and affect other parts of your code, both of which it does successfully. His example makes no sense at all. He shadows a variable and then pretends that it's the same as the parent variable so that he can prove that variables don't always stay the same, because `x == y` is true in one scope and false in another. This doesn't change anything about referential transparency or having assignment, because referential transparency doesn't say that if you copy and paste an expression into a different scope it will have the same value. I wish that instead of getting angry at other people for misunderstanding functional programming, he should try a little harder to actually understand it himself.