3 ms·
Has it? The order pure functions are applied in doesn't matter if their inputs don't change. Here, the inputs do change. The result of handleCollisions is a di
by jorams 11y ago
Has it?
The order pure functions are applied in doesn't matter if their inputs don't change. Here, the inputs do change. The result of handleCollisions is a different state than the state you pass into it, so you should expect a different result when passing it to another function.
Pure functions are trivially parallelizable because they don't depend on non-local state. The moment you know what arguments you are passing to them, you can run them in whatever parallel or non-parallel fashion you like.
Every function that uses and returns a modified version of a single object can not be parallelized, since every single function in the pipeline depends on the result of the previous one. Here, for example, you don't know what the argument you are passing to processInput looks like until you've run handleCollisions.
- threatofrain 11y agoYour statement may be mistaken. The order in which pure functions are applied matters often, but not necessarily. You can think of a few trivial algebraic examples where order matters. f(a) = a + 3 f(b) = 2b f(a).f(b) can have different results vs f(b).f(a)
- grhmc 11y agoIn this case f(a) and f(b) can be called in whatever order, but the . cannot.
- denis1 11y agoI think you misunderstood what the GP is saying. To take your example, given: fun f(a) = a + 3 fun g(b) = 2b Then: val x = f(2) val y = g(3) is equivalent to val y = g(3) val x = f(2) And this is true only because both f and g are pure functions.
- threatofrain 11y agoI don't see why your comment is not simply additive to mine. Both our statements are true, and are related to the general discussion. Your statement relates to the most "pleasingly parallel" situations. Mine refers to problem composability. This was the post right before the one we're talking about: >No, no it isn't. Just like you wouldn't expect 2 3 + 8 to suddenly return 22 when you intend it to, you shouldn't expect the order in which you apply functions to not matter.* A reasonable interpretation of the text and the one that follows is that some claims have been made that functional programming provides benefits of commutativity, and that people are disappointed to find no such benefit.
- dllthomas 11y agoNote that the parent said "if their inputs don't change". In general in this thread, some people are following the root comment in using "order in which functions are applied" to refer to what you mean - applying one function to the output of another, or vice-versa. Of course this affects the correctness of the result (and possibly also the well-typed-ness of the program). Other people, like the author of your parent comment, are using "order in which functions are applied" to mean "order in which functions evaluated", which indeed does not for the correctness of pure functions (except possibly with respect to nontermination). Working with f(x) = x + 3 and g(x) = 2 x, the expression f(g(7)) can be evaluated inside-out or outside-in: f(g(7)) = f(2*7) = 2 * 7 + 3 f(g(7)) = g(7) + 3 = 2 * 7 + 3 As best I can tell, the confusion was introduced in this thread by coldtea's accusations against unspecified FP proponents. Edited to add: per https://news.ycombinator.com/item?id=11396816 https://news.ycombinator.com/item?id=11396816, that should be "coldtea's incorrect accusations against now-specified FP proponents".