Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!sri-unix!cowan%hare.DEC@DECWRL.ARPA
From: cowan%hare.DEC@DECWRL.ARPA
Newsgroups: net.unix
Subject: Re:  Least We Forget:  Multics
Message-ID: <1941@sri-arpa.UUCP>
Date: Fri, 13-Jul-84 05:43:28 EDT
Article-I.D.: sri-arpa.1941
Posted: Fri Jul 13 05:43:28 1984
Date-Received: Tue, 17-Jul-84 06:21:07 EDT
Lines: 24

From:  Ken Cowan ZKO2-3/L13 381-2198 <cowan%hare.DEC@DECWRL.ARPA>


	I have to agree with Andy Tannenbaum that pipes are a marvelous
feature.  If any of you have read Software Tools, remember that one of
the things they stressed was modularity of the design of your program.
Pipes provide another form of subroutine-type modularity, except you
are no longer sharing the global static storage (which is likely to
be the desired effect).

	Once the user is comfortable with pipes, new ideas in the
area of functional languages become very natural.  Functional languages
tend to extend pipe-like constructs to permit more structured data
flow than just sequential passing of data from one process to another

	It is also likely that pipe-like ideas will be an integral part
of the multi-processor computer architectures being developed.  I'm
sure there are better experts than I on this particular subject, since
I have not been following research in this area.

	Ken Cowan
	{ucbvax, decvax, allegra}!decwrl!dec-rhea!dec-hare!cowan
	cowan%hare.DEC@decwrl.arpa
	HARE::COWAN