IMO the really useful part of pipes is less the operator and more the lazy, streaming, concurrent processing model.
So lazy collections / iterators, and HoFs working on those.
The pipe operator itself is mostly a way to denote the composition in reading order (left to right instead of right to left / inside to outside), which is convenient for readability but not exactly world-breaking.
Re:For the Love of Pipes
by beaconstudios on Tuesday January 22, 2019 @07:23AM
(#18967754)
What you're describing sounds a lot like reactiveX - http://reactivex.io/
I only have experience using RxJS, but it's incredibly powerful.
It actually somewhat changes the way you write code, because it enables chaining of calls.
It's worth noting there's nothing preventing this being done before the pipe operator using function calls.
x |> f |> g is by definition the same as (g (f x)).
In non-performance-sensitive code, I've found that what would be quite a complicated monolithic function in an imperative language often ends up as a composition of more modular functions piped together. As others have mentioned, there are similarities with the method chaining style in OO languages.
Also, I believe Clojure has piping in the form of the -> thread-first macro.
[0] https://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasive...