Glad someone posted that link, or I was going to :) Pipes and method chaining "feel" the same. They're both expressions, but with the property that you could

Glad someone posted that link, or I was going to :) Pipes and method chaining "feel" the same. They're both expressions, but with the property that you could rewrite them as what looks like a series of statements without changing the semantics (although possibly changing the efficiency). e.g. usual_suspects.director.surname has the same value ("Singer") as person = usual_suspects.director surname = person.surname surname and cat /etc/passwd | grep root | cut -d: -f6 outputs the same thing (root's home directory) as cat /etc/passwd > tmp1 grep root tmp1 > tmp2 cut -d: -f6 tmp2 > tmp3 cat tmp3 They feel the same because they're both monadic (at least when the chained methods or piped processes behave in certain 'normal' ways). '.' (the method invocation operator) and '|' (the pipe operator) are monadic combinators, just like Haskell's >>= and F#'s |>. And a monadic combinator is just a generalisation of function composition. Monads are going to become a lot more important in the next few years, as programming languages get more expressive and capable of more abstraction. LINQ in C# and VB is a great example - while it looks like they've baked in language support for lots of concepts (querying databases and XML, for data parallelism and for event-driven programming), what they've really done is recognised that those are all forms of monadic computation, baked in language support for one thing (monadic expressions), then implemented those concepts as libraries that any user could have written. (Erik Meijer and Brian Beckman on MS's Channel 9 explain this really nicely.)