4 ms·
> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops. Why not? As in, it just seems like a langu
by KronisLV 3y ago
> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops.
Why not? As in, it just seems like a language design issue, there's no reason why you technically couldn't use the "simpler" syntax. For example, what prevents us from having:
parallel for (Type instance: collection) {
// code for each iteration
}
Of course, there are other reasons to consider using streams and such, though admittedly they can sometimes be cumbersome to work with: especially when you would like to step through all of the transformations that a particular object instance undergoes (or when you map stuff and create new ones, or reduce lists into fewer items), as opposed to needing to tinker with lots of conditional breakpoints in the debugger.
- antonvs 3y ago> Why not? If the construct you propose were feasible, why do you think it doesn’t exist? The reason is that it’s not feasible. Compositional pipelines involve constraints and properties that an imperative for loop doesn’t support.
- KronisLV 3y ago> If the construct you propose were feasible, why do you think it doesn’t exist? Because it already exists as a part of the Stream API in a way that doesn't change the language much: since you can mostly use .parallelStream() or .stream().parallel() there's basically no need for the "old" syntax to enable the same functionality. That doesn't mean that it's somehow unfeasible, since the implementation of the example "parallel for" construct would just need to execute the code in the loop body with a ThreadPool. The Ada language has a nice example of parallel loops like that https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 Of course, there are other benefits to streams and lazy evaluation, but perhaps that's besides the point.