Cool, the pipe command must be one of the most essential things in Unix/Linux based systems.
I would have loved to see some awesome pipe examples though.
For the Love of Pipes
61–70 of 323 posts
Re: For the Love of Pipes
#62For 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)
> When was the last time your Unix workstation was as useful as a Macintosh? Some of that discussion has not aged well :)
The core critique - that everything is stringly typed - still holds pretty well though.
>The receiving and sending processes must use a stream of bytes. Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble. This means that you can’t send an object and the code for the class definition necessary to implement the object. You can’t send pointers into another process’s address space. You can’t send file handles or tcp connections or permissions to access particular files or resources.
Re: For the Love of Pipes
#63Why isn't the pipe a construct that has caught on in 'proper' languages?
Clojure has something that you could call a pipe almost. `->` passes the output from one form to the next one. This example has a nested hash map where we try to get the "You got me!" string. We can either use `:a` (keyword) as a function to get the value. Then we have to nest the function calls a bit unnaturally. Or we can use the thread-first macro `->`, which is basically a unix pipe. user=> (def res {:a {:b {:c "…
Clojure: The Pure Function Pipeline Data Flow
https://github.com/linpengcheng/PurefunctionPipelineDataflow
Re: For the Love of Pipes
#64For 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)
> When was the last time your Unix workstation was as useful as a Macintosh? Some of that discussion has not aged well :)
MacOs is layered on a UNIX-like OS. You can use pipes in your command windows.
Re: For the Love of Pipes
#65The Pure Function Pipeline Data Flow https://github.com/linpengcheng/PurefunctionPipelineDataflow Using the input and output characteristics of pure functions, pure functions are used as pipelines. Dataflow is formed by a series of pure functions in series. A dataflow code block as a function, equivalent to an integrated circuit element (or board)。 A complete integrated system is formed by serial or parallel dataflow…
Yes, there is a strong connection between pipes and functional programming, they all transform what passes through them and should not retain state when implemented properly.
Re: For the Love of Pipes
#66Earlier quoted context omitted.
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.
Interesting question. You could write a executable that accepts piped input and throws it away. When would it exit though? Would it exit successfully at the end of the input stream? That sounds sensible. That would be behaving like an executable wouldn't it?
As long as it does not exit you can still catch it through /proc/
Re: For the Love of Pipes
#67Earlier quoted context omitted.
Clojure has something that you could call a pipe almost. `->` passes the output from one form to the next one. This example has a nested hash map where we try to get the "You got me!" string. We can either use `:a` (keyword) as a function to get the value. Then we have to nest the function calls a bit unnaturally. Or we can use the thread-first macro `->`, which is basically a unix pipe. user=> (def res {:a {:b {:c "…
Clojure: The Pure Function Pipeline Data Flow https://github.com/linpengcheng/PurefunctionPipelineDataflow
Why are you linking to the same github project over and over again?
Re: For the Love of Pipes
#68Earlier quoted context omitted.
> When was the last time your Unix workstation was as useful as a Macintosh? Some of that discussion has not aged well :)
The core critique - that everything is stringly typed - still holds pretty well though. >The receiving and sending processes must use a stream of bytes. Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble. This means that you can’t send an object and the code for the class definition necessary to implement the ob…
> You can’t send pointers into another process’s address space.
Thank goodness.
Re: For the Love of Pipes
#69[Quote] The Unix philosophy is documented by Doug McIlroy as: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.…
Reformatted to be readable: > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. > Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. > Design and build software, e…
If bots were not discouraged on news.yc, I would have implemented a bot for this long ago. Code-block quotes are so atrocious, esp. on mobile devices.
Re: For the Love of Pipes
#70Why 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.
I'm not sure I agree with this. Function composition is more directly comparable to pipes, whereas I tend to think of monads as collapsing structure (i.e. `join :: m (m a) -> m a`)