Glad someone posted that link, or I was going to :)<p>Pipes and method chaining "feel" the same.  They're both <i>expressions</i>, but with the property that you could rewrite them as what looks like a series of <i>statements</i> without changing the semantics (although possibly changing the efficiency).  e.g.<p><pre><code>    usual_suspects.director.surname
</code></pre>
has the same value ("Singer") as<p><pre><code>    person = usual_suspects.director
    surname = person.surname
    surname
</code></pre>
and<p><pre><code>    cat /etc/passwd | grep root | cut -d: -f6
</code></pre>
outputs the same thing (root's home directory) as<p><pre><code>   cat /etc/passwd &#62; tmp1
   grep root tmp1 &#62; tmp2
   cut -d: -f6 tmp2 &#62; tmp3
   cat tmp3
</code></pre>
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 &#62;&#62;= and F#'s |&#62;.  And a monadic combinator is just a generalisation of function composition.<p>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 <i>one</i> thing (monadic expressions), then implemented those concepts as <i>libraries</i> that any user could have written.  (Erik Meijer and Brian Beckman on MS's Channel 9 explain this really nicely.)