10:50 PM
Instead of thinking like that, the point is to think of it as first writing an expression that gives the appropriate Boolean array, and then filtering another array using that filter array.
You don't apply one array onto another array in APL.
There's a subtle "mindset shift" between saying "apply a function to an array" and "write an expression to give an array."
The issue that I try to fight is the tendency to create some helper "predicate" function that is then applied.
It's not that this is inherently a bad thing, but it is very often the case that abstracting into a predicate function just obscures the code.
That sort of thinking leads to things like {(⍺⍺¨⍵)/⍵}
as above.
And the issue with that "pattern" is the Each in there.
I would consider the Each to be the obscuring and undesirable character in that line. By removing it you have better code, and by removing it, that code becomes obviously useless at the same time, which would be precisely the point. With the Each inside of that code, one might be tempted to think that such a pattern was worth encapsulating.
However, with the Each removed from that code, it becomes obvious that the operator is itself a redundancy that can be completely done away with.
Of course, with all of this, keep in mind that I'm very concerned with how our code speaks to us, and how the code suggests, moves, and alters our methods of thinking, and with the HCI of Programming Languages.
So a little thing like whether we use Each there or not makes a big difference.
And in the case of @dzaima's response, the sentiment was that the "inlined" case was a "specific" case, and the Each based case the more general. While that might be true at a semantic level, it's not true at an User level, where in APL, the inlined case is far and away considered to be the canonical, standard case, and the Each version considered to be highly exceptional.
And this has important ramifications for performance, code clarity, conciseness, compilation, and so forth.