Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For the Love of Pipes

blog.jessfraz.com

Post reply on HN
Print view View original

21–30 of 323 posts

Re: For the Love of Pipes

#21

Post by rakoo »

benj111 wrote: post #10

Why isn't the pipe a construct that has caught on in 'proper' languages?

It doesn't look the same, bug go's up.Reader and io.Writer are the interfaces you implement if you want the equivalent of "reading from stdin"/"writing to stdout". Once implemented io.Copy is the actual piping operation.

Re: For the Love of Pipes

#22

Post by MichaelMoser123 »

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 domains that try to exchange a different unit of information between the pipeline elements.

Re: For the Love of Pipes

#23

Post by benj111 »

arianvanp wrote: post #13
benj111 wrote: post #10

Why isn't the pipe a construct that has caught on in 'proper' languages?

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?

Re: For the Love of Pipes

#24

Post by jgtrosh »

benj111 wrote: post #17
analpaper wrote: post #14

Earlier quoted context omitted.

redirect your feelings to /dev/null, because a pipe will just give us a Permission denied

Chmod +x /dev/null (havent tried above, not sure I recommend that you do)

Well you can't read either from /dev/null, and I don't think that's just a question of permissions. I'm pretty sure it's impossible to get /dev/null to behave like an executable.

Re: For the Love of Pipes

#25

Post by xaduha »

benj111 wrote: post #10

Why isn't the pipe a construct that has caught on in 'proper' languages?

To take any significant advantage of it you need to use data-driven, transformational approach of solving something. But funny thing is once you have that it's not really a big deal even if you don't have a pipe operator.

Re: For the Love of Pipes

#26

Post by barrkel »

benj111 wrote: post #10

Why isn't the pipe a construct that has caught on in 'proper' languages?

Monads are effectively pipes; the monad controls how data flows through the functions you put into the monad, but the functions individually are like individual programs in a pipe.

Re: For the Love of Pipes

#27

Post by peterwwillis »

Kipters wrote: post #11
aaaaaaaaaab wrote: post #9

If only there was some standard format to interchange structured data over pipes, other than plain text delimited with various (incompatible) combinations of whitespaces, using various (incompatible) escaping schemes.

That's one of the design goals of Powershell, you don't pass streams of text between cmdlets, you pass objects, which have a type, properties and methods you can use in standard ways (they may also be strings)

A while back I made a PoC that used pipes to create bidirectional json-speaking connections between applications and then distribute the communication between distributed nodes. The idea being, don't just distribute TCP streams between distributed processes, but give 'em objects to make data exchange more expressive. I don't know where my PoC code went, but it wasn't very stable anyway. Just figured it was something we should have adopted by now (but that Plan9 probably natively supports)

Re: For the Love of Pipes

#28

Post by dpwm »

benj111 wrote: post #10

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 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...

Post reply on HN