>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).
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).