I get the feeling the author's total knowledge of functional programming comes from reading -1 comments on Slashdot.

  > It's theoretically possible that the 'f()' or 'x' might
  > change between the lazy evaluation of step one and the
  > lazy evaluation of step three million. Trying to prevent
  > that is what we programmers call a 'hard' problem.

I don't know of any functional language that allows values to change during evaluation.

  > Trying to run functional logic in two or more
  > simultaneous threads can raise serious problems, for
  > instance.

The whole point of using functional programming in multithreaded applications is that it doesn't raise such problems. The data are immutable; one thread doesn't affect the other, unless the programmer explicitly uses stateful constructs like pointers.

  > Myth #2 - Functional programming is 'different from' imperative programming.
  > [...]
  > On the other hand, 'imperative' is also used as a
  > contrast to 'functional', on the basis of really poorly
  > defined terms. The most common version runs something
  > like, "imperative languages use assignment, functional
  > languages don't".. a concept I'll jump up and down
  > upon later.

I've never heard this definition. Ever. It simply doesn't make any sense; of course functional languages use assignment.

  > No, functional programming is not some kind of magic
  > pixie dust you can sprinkle on a computer and banish
  > all problems associated with the business of
  > programming. It's a mindset-altering philosophy and/or
  > worldview, not a completely novel theory of
  > computation. Accept that. Be happy about it. At least
  > friggin' COPE.

This paragraph is completely ridiculous. Functional programming:

1. Is not magic problem-solving pixie dust (obviously).

2. Is not a philosophy, mindset-altering or otherwise.

3. Is a novel theory of computation.

Whether a Turing machine and the lambda calculus are equivalent in power is irrelevant; they are, undeniably, different. Otherwise, there would be no point in using one over the other.

  > Myth #3 - Functional programming is referentially transparent

This entire section deals with Perl, which is not a functional language (as it is not based on the lambda calculus). I don't know enough about Perl to state whether the authors assertions are correct, but regardless, they have nothing to do with functional programming.

The second half of section #3 claims referential transparency is impossible because it requires two values with some external equivalent meaning, such as "three" and "3", to be considered equivalent by the program. At this point I'm wondering whether the entire article is some elaborate prank.

  > Myth #4 - Functional programming doesn't support variable assignment
  > [...]
  > According to Church's thesis, all programming languages
  > are computationally equivalent. They all do the same
  > things, and only the syntactic sugar is different.

Section #4 is already off to a bad start...in fact, reading further, it's just more of the same. Abject confusion, combined with a belief that Perl can be used to demonstrate functional concepts, yielding incomprehensible conclusions.