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.