4 ms·

a includes b is trivial in any language and is not a justification for Junctions. Please take another open minded look at the examples others have posted here.

by raiph 11y ago

a includes b is trivial in any language and is not a justification for Junctions. Please take another open minded look at the examples others have posted here. Post again if you still don't see what they do that's useful and not trivially doable in any language and I'll have a go at explaining them to you.

bhaak 11y ago
Of course the include operation on a set is a trivial operation but that's been the first example for junction I found when googling. It's not a problem with an open mind but rather with understanding what data type a junction is trying to be. If I go to the official specification (my fault, should have gone there from the beginning), I read the definition "A junction is a superposition of data values pretending to be a single data value". But that's a fuzzy definition and it is absolutely not clear what that's supposed to mean. The given examples don't help either. Especially when I look at this discussion and see that several people including you are not sure what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? The autothreading feature is cool but also nothing too special. Every pure functional language can implement map/reduce/filter in parallel. tl;dr I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter.
- raiph 11y ago
  > what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? Afaik junctions are simple and have an obvious intuitive read. But I'm not yet 100% confident of expressing that view without qualification. Given Estragon's "no idea" comment I allowed that my intuitive read might be bogus. In fact the intuitive read is correct: if all(ar1) < any(ar2) # if all in ar1 are numerically less than any in ar2 > The autothreading feature is cool To be clear, the whole point of junctions is autothreading; passing junctions to any code that does not have an overload for junctional arguments is automatically (semantically, at least) data parallelized and that's the win that makes them significant. > Every pure functional language can implement map/reduce/filter in parallel. I note "can implement" and your choice of just three functions. Which languages provide a mechanism equivalent to junctions and their most significant use-case -- automatically generating data parallelized versions of any sequential functionally pure code? > I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter. What equivalent of "all(ar1) < any(ar2)" -- all ar1 less than any ar2 -- is "expressed easier to understand"?

by raiph 11y ago

bhaak 11y ago

Of course the include operation on a set is a trivial operation but that's been the first example for junction I found when googling. It's not a problem with an open mind but rather with understanding what data type a junction is trying to be. If I go to the official specification (my fault, should have gone there from the beginning), I read the definition "A junction is a superposition of data values pretending to be a single data value". But that's a fuzzy definition and it is absolutely not clear what that's supposed to mean. The given examples don't help either. Especially when I look at this discussion and see that several people including you are not sure what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? The autothreading feature is cool but also nothing too special. Every pure functional language can implement map/reduce/filter in parallel. tl;dr I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter.

raiph 11y ago
> what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? Afaik junctions are simple and have an obvious intuitive read. But I'm not yet 100% confident of expressing that view without qualification. Given Estragon's "no idea" comment I allowed that my intuitive read might be bogus. In fact the intuitive read is correct: if all(ar1) < any(ar2) # if all in ar1 are numerically less than any in ar2 > The autothreading feature is cool To be clear, the whole point of junctions is autothreading; passing junctions to any code that does not have an overload for junctional arguments is automatically (semantically, at least) data parallelized and that's the win that makes them significant. > Every pure functional language can implement map/reduce/filter in parallel. I note "can implement" and your choice of just three functions. Which languages provide a mechanism equivalent to junctions and their most significant use-case -- automatically generating data parallelized versions of any sequential functionally pure code? > I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter. What equivalent of "all(ar1) < any(ar2)" -- all ar1 less than any ar2 -- is "expressed easier to understand"?