Although this article has plenty of interesting things to say, it also often misses the point of functional programming. Starting off with closures as a data privacy mechanism demonstrates some of the issues. That feels like an OO concern more than an FP one. Then focusing on the applications to continuous rather than discrete data also misses most of the point of modern FP. IMHO, that's not really a significant concern. There is some historical reason to note that it was of interest to the LISP community years ago, but it has little to do with modern FP. Misusing `idempotent` is another red flag. `Idempotent` can have several definitionss, but none of them correspond to returning "the same output, regardless of the number of times the function is called." One definition -- when side effects are allowed -- is that the global state remains the same after subsequent calls as it was after the first call. Another, for pure functions, is simply that for all x, f(f(x)) == f(x). Neither of these concepts is near the core of FP. "[P]ure functions produce stronger guarantees of encapsulation than objects without function purity." While that might be useful, the general FP concerns have to do with predicatibility, repeatibility, the ability to break the problem down into small understandable pieces. Words like "encapsulations" add nothing to this understanding, and only distract us. I think the author needs to work a little more with FP, ideally in an FP language, but at least using JS in a more purely FP manner before he can comfortably teach it. This sounds like the French teacher, who took a little Spanish in college, and had a few courses in how to teach it, but is not really fluent, trying to cover for the Spanish teacher's absense.