Echo JS 0.11.0

<~>
ericelliott 3608 days ago. link parent 1 point ▲ ▼
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".

Replies

CrossEye 3595 days ago. link 2 points ▲ ▼
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.