views:

678

answers:

9

In Unix shell programming the pipe operator is an extremely powerful tool. With a small set of core utilities, a systems language (like C) and a scripting language (like Python) you can construct extremely compact and powerful shell scripts, that are automatically parallelized by the operating system.

Obviously this is a very powerful programming paradigm, but I haven't seen pipes as first class abstractions in any language other than a shell script. The code needed to replicate the functionality of scripts using pipes seems to always be quite complex.

So my question is why don't I see something similar to Unix pipes in modern high-level languages like C#, Java, etc.? Are there languages (other than shell scripts) which do support first class pipes? Isn't it a convenient and safe way to express concurrent algorithms?

Just in case someone brings it up, I looked at the F# pipe-forward operator (forward pipe operator), and it looks more like a function application operator. It applies a function to data, rather than connecting two streams together, as far as I can tell, but I am open to corrections.

Postscript: While doing some research on implementing coroutines, I realize that there are certain parallels. In a blog post Martin Wolf describes a similar problem to mine but in terms of coroutines instead of pipes.

+3  A: 

You can find something like pipes in C# and Java, for example, where you take a connection stream and put it inside the constructor of another connection stream.

So, you have in Java:

new BufferedReader(new InputStreamReader(System.in));

You may want to look up chaining input streams or output streams.

James Black
A very good point!
DroidIn.net
I was thinking more about two separate processes running in parallel one spitting out data, and the other consuming data.
cdiggins
Then you just use a PipedInput (Output) Stream: http://java.sun.com/javase/6/docs/api/java/io/PipedInputStream.html, but this is not in parallel, but you can convert data as you go through the streams.
James Black
@James, the PipedInputStream and PipedOutStream is very close to what I am looking for. I was wondering about first class support for this thing (with automatic parallelism) in languages. Turns out that what I was looking for is called "flow programming". Thank you very much though for showing me some cool Java stuff.
cdiggins
+3  A: 

You can do pipelining type parallelism quite easily in Erlang. Below is a shameless copy/paste from my blogpost of Jan 2008.

Also, Glasgow Parallel Haskell allows for parallel function composition, which amounts to the same thing, giving you implicit parallelisation.

You already think in terms of pipelines - how about "gzcat foo.tar.gz | tar xf -"? You may not have known it, but the shell is running the unzip and untar in parallel - the stdin read in tar just blocks until data is sent to stdout by gzcat.

Well a lot of tasks can be expressed in terms of pipelines, and if you can do that then getting some level of parallelisation is simple with David King's helper code (even across erlang nodes, ie. machines):

pipeline:run([pipeline:generator(BigList),
          {filter,fun some_filter/1},
          {map,fun_some_map/1},
          {generic,fun some_complex_function/2},
          fun some_more_complicated_function/1,
          fun pipeline:collect/1]).

So basically what he's doing here is making a list of the steps - each step being implemented in a fun that accepts as input whatever the previous step outputs (the funs can even be defined inline of course). Go check out David's blog entry for the code and more detailed explanation.

Mark Aufflick
This is very much along the lines of what I am thinking about. I need to study it a bit more tomorrow after some coffee!
cdiggins
I accepted this answer, because it is the most elegant solution I saw and Mark pointed me to Hartmann pipelines in the above comment, which lead me to Flow-based programming.
cdiggins
+1  A: 

I think the most fundamental reason is because C# and Java tend to be used to build more monolithic systems. Culturally, it's just not common to even want to do pipe-like things -- you just make your application implement the necessary functionality. The notion of building a multitude of simple tools and then gluing them together in arbitrary ways just isn't common in those contexts.

If you look at some of the scripting languages, like Python and Ruby, there are some pretty good tools for doing pipe-like things from within those scripts. Check out the Python subprocess module, for example, which allows you to do things like:

proc = subprocess.Popen('cat -',
                       shell=True,
                       stdin=subprocess.PIPE,
                       stdout=subprocess.PIPE,)
stdout_value = proc.communicate('through stdin to stdout')[0]
print '\tpass through:', stdout_value
swillden
+1  A: 

Objective-C has the NSPipe class. I use it quite frequently.

Dave DeLong
+2  A: 

Usually you just don't need it and programs run faster without it.

Basically piping is consumer/producer pattern. And it's not that hard to write those consumers and producers because they don't share much data.

  • Piping for Python : pypes
  • Mozart-OZ can do pipes using ports and threads.
egon
Pypes, is very awesome and much along the lines of what I was thinking.
cdiggins
+1  A: 

I've had a lot of fun building pipeline functions in Python. I have a library I wrote, I put the contents and a sample run here. The best fit me for has been XML processing, described in this Wikipedia article.

Joel
+1 for the wikipedia article link. :-)
cdiggins
+4  A: 

Haha! Thanks to my Google-fu, I have found an SO answer that may interest you. Basically, the answer is going against the "don't overload operators unless you really have to" argument by overloading the bitwise-OR operator to provide shell-like piping, resulting in Python code like this:

for i in xrange(2,100) | sieve(2) | sieve(3) | sieve(5) | sieve(7):
    print i

What it does, conceptually, is pipe the list of numbers from 2 to 99 (xrange(2, 100)) through a sieve function that removes multiples of a given number (first 2, then 3, then 5, then 7). This is the start of a prime-number generator, though generating prime numbers this way is a rather bad idea. But we can do more:

for i in xrange(2,100) | strify() | startswith(5):
    print i

This generates the range, then converts all of them from numbers to strings, and then filters out anything that doesn't start with 5.

The post shows a basic parent class that allows you to overload two methods, map and filter, to describe the behavior of your pipe. So strify() uses the map method to convert everything to a string, while sieve() uses the filter method to weed out things that aren't multiples of the number.

It's quite clever, though perhaps that means it's not very Pythonic, but it demonstrates what you are after and a technique to get it that can probably be applied easily to other languages.

Chris Lutz
Not bad. I voted up of course, but my qualms are none of the functions are executed in parallel. What I really want is something more like the Erlang and Java answers.
cdiggins
@cdiggins - Your qualms are an implementation detail. This same functionality could have easily been implemented in C (or even assembly?) to take advantage of parallelism, and because all the brute work is done in the base class, derived classes written in pure Python would still get that power (the two methods that you have to overload - `map` and `filter` - only work on one element at a time). Of course, if we're willing to implement it, we could do the same for most regular functional constructs, with or without the Unix-pipe interface.
Chris Lutz
+1 for beauty and horror at the same time.
Stefano Borini
A: 

Thanks to all of the great answers and comments, here is a summary of what I learned:

It turns out that there is an entire paradigm related to what I am interested in called Flow-based programming. A good example of a language designed specially for flow-based programming is Hartmann pipelines. Hartamnn pipelines generalize the idea of streams and pipes used in Unix and other OS's, to allows for multiple input and output streams (rather than just a single input stream, and two output streams). Erlang contains powerful abstractions that make it easy to express concurrent processes in a manner which resembles pipes. Java provides PipedInputStream and PipedOutputStream which can be used with threads to achieve the same kind of abstractions in a more verbose manner.

cdiggins
A: 

Are you looking at the F# |> operator? I think you actually want the >> operator.

Nathan Phillips