Path: utzoo!attcan!uunet!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!ccu!salomon
From: salomon@ccu.umanitoba.ca (Dan Salomon)
Newsgroups: comp.lang.visual,comp.lang.misc
Subject: Re: metaphor and programming
Message-ID: <1989Nov23.162521.4022@ccu.umanitoba.ca>
Date: 23 Nov 89 16:25:21 GMT
References: <13770@orstcs.CS.ORST.EDU> <7000@ficc.uu.net> <1989Nov17.040858.22886@rpi.edu>
Reply-To: salomon@ccu.UManitoba.CA (Dan Salomon)
Organization: University of Manitoba, Winnipeg, Manitoba, Canada
Lines: 19

In article <1989Nov17.040858.22886@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes:
>I am not so sure about this.  Let's stay with the example of a Unix pipe
>"program".  This is always a one-dimensional flow of data.  I am not
>sure that a visual representation of this would add anything, although
>it might make building pipes more fun.

That's the whole point: UNIX pipes are one dimensional because
they have to be represented in text.  By having a visual shell
you could have two dimensional pipes.

A few TEE programs have been written, that let you send the same output
two places at once, but multiple standard inputs & outputs would be
more useful.  For example you may want to take an input file and a
stream of update commands (two standard inputs), pipe command errors to
the terminal, a modification list to the printer, and an updated file
to a post-processing consistency checker (three standard outputs).  One
of the reasons that UNIX compilers don't provide source listings with
embedded error messages, is that this would require two standard
outputs, one for the listing and one for the task image.