Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!decvax!cca!ima!haddock!dan
From: dan@haddock.UUCP
Newsgroups: net.unix
Subject: Re: Least We Forget:  MULTICS - (nf)
Message-ID: <213@haddock.UUCP>
Date: Thu, 12-Jul-84 18:20:34 EDT
Article-I.D.: haddock.213
Posted: Thu Jul 12 18:20:34 1984
Date-Received: Thu, 19-Jul-84 02:09:18 EDT
Lines: 27

#R:sri-arpa:-160800:haddock:16700029:000:1451
haddock!dan    Jul 11 17:35:00 1984

From barmar at mit-eddie:

> ... pipes are a kludge to get around the fact that dynamic linking was hard
> to implement, so instead of making it easy to call lots of subroutines, you
> start up a process and read its output.

In theory this might be true.  In practice it isn't, because Multics programs
aren't set up to be coupled together the way UNIX programs are, either through
dynamic linking or any other way.  I've had to cascade a series of operations
using different Multics programs, and it just isn't as simple as 'prog1|prog2'.
You can't dynamically link them together because they don't know how to call
each other.  You can redirect user_input and user_output (I/O streams), but you
can't just couple user_output from one program into user_input of the
next--because the next program typically can't be told to read user_input for
its data; it only understands about named files.  To do a UNIX 'prog1 | prog2',
you have to say something like
    file_output temp	(redirect user_output into file "temp")
    prog1 input 	(run prog1; its output is being collected in temp)
    file_output 	(redirect user_output back to the terminal)
    prog2 temp		(so you can see prog2's output)
And that only works if prog1 actually prints its output, rather than modifying
the input file, which many programs do.  I'll take the UNIX 'kludge' any day!
Also, pipes implement coroutine-style linkage rather than call-return, which
is often more useful.