As the article shows, though, predictable does not mean anything like logical!
Please don't count on this for anything serious. The thought that `{x: 1, y: 2}` has different behavior than `{y: 2, x: 1}` is fairly horrifying.
How long before today's magic looks just as dated as yesterday's?
I find it fairly amusing that the author describes a recent experience with the shine fading on one magical solution only to go on to extol the next one.
But why would people choose lodash-fp over lodash (lodash-classic? :-> ) if, as you say, it reduces performance? Why would they choose lodash-fp over Ramda, which values that style API, whereas you've been arguing against it?
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.
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.
This article has been around a while. And while Eric Elliot may have some good points, his arguments are circular and his tone is far too strident. He seems unwilling to believe that other points of view have any real legitimacy.
For a better-argued version of the same ideas, see Kyle Simpson's posts on David Walsh's blog, starting with http://davidwalsh.name/javascript-objects
...because the 4,927 other similar solutions out there doing the same thing weren't good enough.
Let's see, there's Classy, Lineage, Klass, ooplib, JSFace, offerings from MooTools, Dojo, YUI, and so many more...
And all trying to solve the non-problem that Javascript is a different type of language than Java.
As the article shows, though, predictable does not mean anything like logical! Please don't count on this for anything serious. The thought that `{x: 1, y: 2}` has different behavior than `{y: 2, x: 1}` is fairly horrifying.