Echo JS 0.11.0

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.

I agree on the observations you made. I think the real value of the article - and the reason why i re-tweeted/recommended it - is in its "evangelist" approach, exposing FP concepts to programmers, especially in a language, Javascript, where the next spec includes a keyword (class) introduced to placate OOP developers who can't get their head around prototypal inheritance and FP in javascript. What is most ironic is that the last article I recommended on twitter before Eric Elliott's one is your FP slides at http://scott.sauyet.com/Javascript/Talk/2014/01/FuncProgTalk/

Your comments have some merit, but what you don't seem to be considering is that the article wasn't written for FP experts. It was written for people who are probably a lot more familiar with OOP, which is why I used more OOP jargon than FP jargon.

Your take on whether or not idempotence is important surprised me. The very first sentence from wikipedia: "Idempotence (/ˌaɪdɨmˈpoʊtəns/ eye-dəm-poh-təns) is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application." This is a commonly understood definition in CS, and by that definition, all pure functions are idempotent -- important for many of the same reasons that idempotence is important in HTTP architectures (see http://restcookbook.com/HTTP%20Methods/idempotency/).

As I mentioned in the article, this property of pure functions strikes me as particularly relevant to web platform developers because it means that you can safely distribute computation without changing the results. Distributed computing is one of the reasons that I believe FP is going to be increasingly important in the future.

I'm not conflating idempotence with function purity. Not all idempotent functions are pure (they can have an initial side-effect, for instance, deleting or creating a resource), but all pure functions are idempotent.

I think your language analogy rings true because you're confused about the audience I'm talking to. If all the students speak French, but very little or no Spanish at all, it's probably helpful to start out speaking a little French just to give students some initial context and grounding.

If I were writing for an audience of FP experts, I'd be using words like "thunk" and "homomorphism" instead of "idempotence" and "encapsulation".

To me the trouble with the article was not that the jargon was that of OOP, but that the underlying concerns seemed to be those of OOP rather than those of FP.  Often there is a substantial difference.

Idempotence, in the mathematical sense (i.e. f(f(x)) == f(x) for all x) is rarely that important in FP.  Sure there are functions that exhibit it, ones like absolute value, but it's more a curiosity than a fundamental concern.  Idempotence in the computer science sense is all about side effects, and how the side effects only happen once.  But FP is generally concerned with the elimination of, or at least severe constraining of side effects.  Functional programming is instead concerned with referential integrity, the notion that expressions can freely be exchanged for their values without changing the behavior of a system.  While this is related, it's substantially different from idempotence.

Honestly, I hope you won't use the word "homomorphism".  I had enough of that in grad school!  :-)  Perhaps I do misunderstand, but I just re-read the article and it still reads to me more like an "How to manage your OOP ideas with FP techniques" article than one such as "What's FP? (for OOP devs)".  The end of it, beginning with "Lists as a Generic Interface", is better than the beginning, IMHO.  But even there are some odd ideas such as odd definition of "lifting".

But I do want to say that I'm glad to see you writing about this.  The fact that you're discussing FP is much more important in my mind than any flaws I do see.  You and I have had our disagreements over OOP techniques.  This is much dearer to my heart, and I'm glad we're not as far apart here.