3 ms·

This is an odd complaint. Immutability doesn't make order of operations go away. (x+1)/2 is not the same operation as (x/2)+1. I find the tangent into effect s

This is an odd complaint. Immutability doesn't make order of operations go away. (x+1)/2 is not the same operation as (x/2)+1. I find the tangent into effect systems at the end to be somewhat ironic, given what it follows. Effect systems also don't make order of operations not matter. The order in which effect handlers are run can change the semantics of code using them. Pairs of operations don't commute in general. There's no way around knowing which order things need to apply in. (x/2)+1 and (x+1)/2 are just different operations. Nothing saves you from needing to choose which one you mean.

manmal 5y ago
Thanks for voicing this - in the system I work with (Swift Composable Architecture), concurrently dispatched effects are processed in the order in which they return the result of their work. The scheduler processes effect results on a single thread, so no real concurrency can happen there. If two supposedly concurrent effects mutate the same substate, then the outcome is (in theory) not even deterministic - the effect returning from their work first will „win“.
didibus 5y ago
Exactly this ^ While effect systems are cool, they don't solve the problem described here, which is just that you need to be clear about the order of operations that are order dependent. The question would be, what programming style lets you most simply describe the operations and their needed order? Functional programming is often also talked to as a type of dataflow programming, and the two share a lot in common. A dataflow approach in my opinion is best suited here, and functional programming can easily be used in a dataflow style. The author's first example is actually pretty great, it defines a pipeline of operations, the pipeline is a very clear way to declare the order of operations. Another popular approach is instead of explicitly declaring the order using dataflow constructs like a pipeline or a DAG, that you define the dependencies on prior operations and data, and the construct infers the order from those declared dependencies.
dgb23 5y ago
I have to agree here. The author confuses what immutability is about by implicitly extending to control issues which are orthogonal to immutability. The author describes the problem very well but misuses the term "state" to describe "control". The solution to control issues is not having your code depend on order. Logic programming, SQL, schema, type declarations, regex... Many of us use these all the time but logic/declarative programming in general is not the norm in $dayJobLang.

manmal 5y ago

Thanks for voicing this - in the system I work with (Swift Composable Architecture), concurrently dispatched effects are processed in the order in which they return the result of their work. The scheduler processes effect results on a single thread, so no real concurrency can happen there. If two supposedly concurrent effects mutate the same substate, then the outcome is (in theory) not even deterministic - the effect returning from their work first will „win“.

didibus 5y ago

Exactly this ^ While effect systems are cool, they don't solve the problem described here, which is just that you need to be clear about the order of operations that are order dependent. The question would be, what programming style lets you most simply describe the operations and their needed order? Functional programming is often also talked to as a type of dataflow programming, and the two share a lot in common. A dataflow approach in my opinion is best suited here, and functional programming can easily be used in a dataflow style. The author's first example is actually pretty great, it defines a pipeline of operations, the pipeline is a very clear way to declare the order of operations. Another popular approach is instead of explicitly declaring the order using dataflow constructs like a pipeline or a DAG, that you define the dependencies on prior operations and data, and the construct infers the order from those declared dependencies.

dgb23 5y ago

I have to agree here. The author confuses what immutability is about by implicitly extending to control issues which are orthogonal to immutability. The author describes the problem very well but misuses the term "state" to describe "control". The solution to control issues is not having your code depend on order. Logic programming, SQL, schema, type declarations, regex... Many of us use these all the time but logic/declarative programming in general is not the norm in $dayJobLang.