If the code is commutative, then this that statement is true.
But functional programming isn't going to make a non-commutative problem magically commutative.
All code has inherently serial parts (eg because of dependency chains). These cannot be magically made parallel (although, especially with immutable data, it may be possible to apply parallelism techniques like pipelining). However, the parts that are independent can be trivially parallelizable. Immutable state and functional programming make it easier to tease this out, but it doesn't automatically eliminate dependencies or allow them to be evaluated in arbitrary order.
>If the code is commutative, then this that statement is true.
Actually my statement is true whether code is commutative or not -- since my statement wasn't that "pure functions can run at any order" but rather "people has been claiming often that pure functions can run at any order".
What they claiming can be right or wrong (depending on the commutative nature of the functions in their code), but that people indeed claim it is true (and can be quantifiably verified)...
Barring people who are new to FP and reading through a tutorial, who can make erroneous claims out of lack of understanding (just like people learning OOP also make mistaken claims about it), I don't see how anyone using FP can make that claim. It's evident that you cannot arbitrarily change the order in a series of transformations unless they are commutative. I mean, this is already the case with maths! Who would claim it isn't with FP?
Yes, thank you, I wrote this comment and then saw your other comment. Below that comment I explained why I think your interpretation of what those people are claiming is mistaken. Mind you, not a case of No True Scotsman: I'm saying they aren't arguing what you say they are arguing; at worst they are being unclear, but they are certainly arguing something very different!
But functional programming isn't going to make a non-commutative problem magically commutative.
All code has inherently serial parts (eg because of dependency chains). These cannot be magically made parallel (although, especially with immutable data, it may be possible to apply parallelism techniques like pipelining). However, the parts that are independent can be trivially parallelizable. Immutable state and functional programming make it easier to tease this out, but it doesn't automatically eliminate dependencies or allow them to be evaluated in arbitrary order.