Hacker News Reader

I think you're being disingenuous. Those articles aren't claiming what you say they are claiming. Their wording may be imprecise (I agree with you on that), but nobody is claiming that FP makes all chains of transformations magically commutative.

You know what these people mean when they say pure functions may be evaluated in any order: that as long as they have the same input, the result will be the same. But in contrast, the "magical commutativity" property doesn't mean the functions get called with the same input! Or, to say the same in other words, you cannot change a function and expect your program to be the same, and we know that h1 = f . g and h2 = g . f are, in the general case, NOT the same function! In fact, one of the two might not even compile!

At best you could argue the explanations you linked to are incomplete or unclear. But it's dishonest to say they claim you can order the functions in any way, regardless of their input -- which is what TFA was having problems with.

>I think you're being disingenuous. Those articles aren't claiming what you say they are claiming. Their wording may be imprecise (I agree with you on that), but nobody is claiming that FP makes all chains of transformations magically commutative.

But I didn't say they do [say the latter].

Only that they sidestep the issue -- often confusing application with evaluation (using them interchangeably, or e.g. using the imprecise "run in any order" instead of evaluate).

Very few of those article mention commutativeness, the distinction between evaluation and application, data dependencies, etc. And even those ment

ioning "order of evaluation" forgetting to clarify that is not the same as application, and confusing the matters more by adding that we can "easily run them all in parallel" (giving newcomers the impression that the order of application doesn't matter at all).

>At best you could argue the explanations you linked to are incomplete or unclear. But it's dishonest to say they claim you can order the functions in any way, regardless of their input -- which is what TFA was having problems with.

TFA author had those problems (or, more precisely, had the idea that they shouldn't exist) because he was influenced by such articles -- coming to believe that FP was "supposed to free us" from ordering issues.

You say that "it's dishonest to say they claim you can order the functions in any way, regardless of their input", but that's just what this statement implies:

"A pure function is also robust. Its order of execution doesn’t have any impact on the system."

Potential issues with input not mentioned at all, as if they don't exist.

Or this:

"Pure functions can be evaluated in any order, the result is always the same. Therefore, pure functions calls can be run in parallel"

Here they indeed write "evaluation", but the "can be run in parallel" sans qualifications, muddies the waters.

I don't follow you. When people say "you can run these functions in any order" (or "in parallel"), how do you interpret this to also imply "...regardless of their input"?

Why does it matter if they say "run" instead of "evaluate"? What's the difference, in your opinion?

Do people really have trouble with the (universal, not FP-specific) notion that the input to a function matters?

Do we both agree that FP/immutability doesn't promise what the author of the article thinks it promises, and that people (regardless of about how clearly they say it) do not claim it does?

>Why does it matter if they say "run" instead of "evaluate"? What's the difference, in your opinion?

"Evaluation" solely implies passing an actual value and getting the result from a function. Taken in isolation, each evaluation (of pure functions) is independent from whether 10 or 200 other happened before or after -- it depends only on the input it gets.

Saying "run" on the other hand can be conflated to mean running a pure function in the course of a program's execution, and there the order or execution can matter with regards to the overall program's behavior, e.g. when it affects the derived input of a subsequent function.

>Do people really have trouble with the (universal, not FP-specific) notion that the input to a function matters?

Yes, people do expect pure functions will free them from race conditions for example -- only to discover that they still exist, as the author did, at a higher conceptual level.

Heck, if we are to discuss the original article, isn't it a given that such people as its author do exist and have the same confusion?

Or does the author seem like some totally ignorant programmer that is not representative of more people (and that we'd expect him/her to get it all wrong)? It doesn't come out that way to me.

You're mistaking order of evaluating separate functions, from function composition. So if I have two pure functions, f and g, that take and return immutable values (thus having no side effects) I can go:

a = f(x)

b = g(y)

or:

b = g(y)

a = f(x)

And the order does not matter. Because each function cannot effect the other. This is what these quotes are talking about. That independence. There's no outside state mutated in one evaluation affecting the other evaluation.

What you're talking about is function composition. That it f(g(x)) vs g(f(x)). And as many others have said on these threads, the order of the functions when composing two functions together like this is only unimportant if the functions themselves are commutative.

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.

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