About forty years ago, Unix arrived with far more than a new operating system. It helped establish C, sockets, open-source practice, hacker culture, and a set of ideas that went on to influence the wider development of computing.
Among Unix’s most consequential inventions was the pipe. Its purpose was straightforward: connect programs with different jobs so they could communicate and pass their output to one another. That simple mechanism encouraged software to be built from small, focused components rather than large, tightly entangled systems.
A program could concentrate on one task and do it well, while another program handled the next step. The result was a style of development built around high cohesion and low coupling, along with the familiar Unix preference for simplicity. This way of thinking has continued to influence software architecture, all the way into modern cloud computing.
The pipe is associated with Malcolm Douglas McIlroy, one of Unix’s creators and one of the people who helped shape Unix culture. He summarized the underlying philosophy in terms that remain remarkably clear:
A program should focus on one purpose and do that job as well as possible. Programs should be designed to work together. They should process text streams, because text provides a universal interface.
The first printed description of the pipe appeared on October 11, 1964. McIlroy compared the idea to a garden hose: when another step of data processing becomes necessary, simply attach another section.
The complete text reads:
- 10 -
Summary--what's most important.
To put my strongest concerns into a nutshell:
1. We should have some ways of connecting programs like
garden hose--screw in another segment when it becomes when
it becomes necessary to massage data in another way.
This is the way of IO also.
2. Our loader should be able to do link-loading and
controlled establishment.
3. Our library filing scheme should allow for rather
general indexing, responsibility, generations, data path
switching.
4. It should be possible to get private system components
(all routines are system components) for buggering around with.
M. D. McIlroy
October 11, 1964
There is little need to paraphrase the passage. Its language is direct, and its central image is easy to understand: connect programs the way sections of a garden hose are joined together. That modest proposal became one of the defining ideas behind the Unix way of building software.