I think this article raises a great point overall, but the Fibonacci example is a bit weak and smacks of a strawman. Functional programming tutorials that teach

I think this article raises a great point overall, but the Fibonacci example is a bit weak and smacks of a strawman. Functional programming tutorials that teach you to write a recursive Fibonacci or factorial calculator are not doing so with the purpose of teaching a useful function, or even a workable one - in fact, more often than not this is called out by showing its performance for moderately large N. They only use those examples because they're simple, abstract problems that can be used to elegantly demonstrate recursion in a relatable way. If we're going to talk about real world, practical applications, then it might be more relevant to bring up a problem for which there isn't a trivial O(1) solution. A dynamic programming problem, perhaps? It's glossed over with a terse dismissal: > “Advanced” discussions might consider engineering considerations such as tail-call behavior, or the possibility of memoizing results. ... But this is exactly why a functional programming language might be better than an imperative for certain applied mathematics problems. Note, I'm not saying that it is better, just that it's not such a simple argument. With a different set of examples, this article could have been written in favor of Lisp just as easily. I still think it's a good article overall, just that the point it tries to sneak in about Lisp and functional programming is a little shaky.