3 ms·

It's clear that you know what is actually meant by "order doesn't matter". However, I find the idea that FP advocates have been ambiguous in using this phrase

It's clear that you know what is actually meant by "order doesn't matter". However, I find the idea that FP advocates have been ambiguous in using this phrase to be preposterous. In none of the examples you cite does the other say "order doesn't matter" without qualification. In every example you cite, the author explicitly says that order of evaluation/execution doesn't matter. That is an unambiguously correct statement. That being said, it is still possible to be unambiguously correct and still regularly confuse people. Rhetorical style and knowing your audience go a long way towards avoiding that sort of confusion. However even when you write with clarity, there will still be some who will misinterpret - this cannot be helped. I recognize this is merely my personal experience, but even as an average programmer who was haphazardly exploring the concepts of FP, I don't think I ever misunderstood what was meant by "order doesn't matter". If it turns out that many/most people were confused, then I will consider myself lucky in having found some good introductory material. Otherwise, I'm inclined to think that this is one of those blindingly obvious things, and that people who fell into this confusion - while by no means stupid - were simply exercising poor reading comprehension when they came across that phrase.

coldtea 11y ago
>However, I find the idea that FP advocates have been ambiguous in using this phrase to be preposterous. And yet the author of the original article, writes: >It turns out that our purely functional rendering code is sensitive to ordering in non-obvious ways. The first time I encountered this kind of bug, it felt strangely familiar – it’s something that often occurs in imperative programs. And notes: >This is exactly the kind of problem that functional programming was supposed to help us avoid! [empasis mine] That the author felt that way is a failure from those intro to FP blog posts/articles that failed to make such things clear. >In none of the examples you cite does the other say "order doesn't matter" without qualification. They all fail to mention that those functions can have data dependencies from one another, and that we can't easily parallelize "any" of them as they claim. None of the articles mentions anything about the commutativity of the calculations (or even the very term commutative itself).

coldtea 11y ago

>However, I find the idea that FP advocates have been ambiguous in using this phrase to be preposterous. And yet the author of the original article, writes: >It turns out that our purely functional rendering code is sensitive to ordering in non-obvious ways. The first time I encountered this kind of bug, it felt strangely familiar – it’s something that often occurs in imperative programs. And notes: >This is exactly the kind of problem that functional programming was supposed to help us avoid! [empasis mine] That the author felt that way is a failure from those intro to FP blog posts/articles that failed to make such things clear. >In none of the examples you cite does the other say "order doesn't matter" without qualification. They all fail to mention that those functions can have data dependencies from one another, and that we can't easily parallelize "any" of them as they claim. None of the articles mentions anything about the commutativity of the calculations (or even the very term commutative itself).