31–40 of 323 posts
Why isn't the pipe a construct that has caught on in 'proper' languages?
julia> 1:5 |> x->x.^2 |> x->2x
5-element Array{Int64,1}:
2
8
18
32
50I think the Unix pipeline works because this it has this moldable and expressive text substance that is exchanged. Gstreamer also has pipelines, but the result in my opinion is quite awkward because events of many types are exchanged. Windows Powershell also has a pipeline where objects are exchanged, but it also somehow failed to become a huge success. i think the unix pipeline concept doesn't quite scale to other d…
For an alternative view, don't forget to read the section on Pipes of The Unix-Haters Handbook : http://web.mit.edu/~simsong/www/ugh.pdf (page 198)
Some of that discussion has not aged well :)
Why isn't the pipe a construct that has caught on in 'proper' languages?
OCaml has had the pipe operator |> since 4.01 [0] 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 imperati…
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.
I think the Unix pipeline works because this it has this moldable and expressive text substance that is exchanged. Gstreamer also has pipelines, but the result in my opinion is quite awkward because events of many types are exchanged. Windows Powershell also has a pipeline where objects are exchanged, but it also somehow failed to become a huge success. i think the unix pipeline concept doesn't quite scale to other d…
While I do agree they can sometimes be tricky to use, Gstreamer pipelines are also it's best feature. Is there a better way?
Why isn't the pipe a construct that has caught on in 'proper' languages?
Earlier quoted context omitted.
It is! It's the main way of programming in lazy functional programming languages like Haskell And many programming languages have libraries for something similar:. iterators in rust / c++, streams in java/c#, thinks like reactive
Haskell was the only possible I found. Iterators don't really fully capture what a pipe is though? Theres no parallelism. And streams don't have the conceptual simplicity of a pipe?
Pipes are concurrent, not necessarily parallel. Iterators are concurrent, and can be parallel (https://docs.rs/rayon/0.6.0/rayon/par_iter/index.html).
I recently came across Ramda CLI's interactive mode [1] It essentially hijacks pipe's input and output into browser where you can play with the Ramda command. Then you just close browser tab and Ramda CLI applies your changed code in the pipe, resuming its operation. Now I'm thinking all kinds ways I use pipe that I could "tee" through a browser app. I can use browser for interactive JSON manipulation, visualization…
a |1 b | c | d, |1 e
Why isn't the pipe a construct that has caught on in 'proper' languages?