3 ms·
It has, in the form of function composition, as other replies show. However, the Unix pipe demonstrates a more interesting idea: composable programs on the leve
by VladimirGolovin 8y ago
It has, in the form of function composition, as other replies show. However, the Unix pipe demonstrates a more interesting idea: composable programs on the level of the OS.
Nowadays, most of the user-facing desktop programs have GUIs, so the 'pipe' operator that composes programs is the user himself. Users compose programs by saving files from one program and opening them in another. The data being 'piped' through such program composition is sort-of typed, with the file types (PNG, TXT, etc) being the types and the loading modules of the programs being 'runtime typecheckers' that reject files with invalid format.
On the first sight, GUIs prevent program composition by requiring the user to serve as the 'pipe'. However, if GUIs were reflections / manifestations of some rich typed data (expressible in some really powerful type system, such as that of Idris), one could imagine the possibility of directly composing the programs together, bypassing the GUI or file-saving stages.
- sideeffffect 8y agomaybe I'm being overly pedantic, but people seem to be confused about this: the pipes in your typical functional language (`|>`) is not a form of function composition, like ``` f >> g === x -> g(f(x)) ``` but function application, like ``` f x |> g === g(f(x)) x |> f |> g // also works, has the same meaning f |> g // just doesn't work, sorry :( ```
- chriswarbo 8y ago> the pipes in your typical functional language (`|>`) is not a form of function composition What is a "typical functional language" in this case? I don't think I've come across this `|>` notation, or anything explicitly referred to as a "pipe", in the functional languages I tend to use (Haskell, Scheme, StandardML, Idris, Coq, Agda, ...); other than the Haskell "pipes" library, which I think is more elaborate than what you're talking about.