The author does have a point. Another issue is that the problems FP solves are problems that I think many developers genuinely don&#x27;t have. Or when they do have them, they occur in very specific ways that can easily be handled with an 80% solution bolted onto an existing imperative-first language. Node, LINQ and Numpy all come to mind. These have the advantage of confining the weirdness to one spot, which makes it easier for users to accept them because they don&#x27;t feel trapped the way they might in a language like Haskell or Racket.<p>Meanwhile, FP does introduce some of its own problems, and I think many of my fellow FP fans are too quick to downplay them. Performance is one. It might be solvable by compilers, but for those of us who are not likely to spend much time hacking on the compiler for our language of choice that&#x27;s a small consolation.<p>The end result being, it&#x27;s still the case that my adventures in functional programming (which are generally done using a multiparadigm language like F# or Scala) will go something like this more often than I care to admit:<p><pre><code>  1. Implement imperative solution.
  2. Feel guilty, go back and replace it with functional one.
  3. Find performance problem. Dig out optimizer.
  4. Optimizer points to code from step 2.
  5. Revert back to version from step 1.</code></pre>