🚀 go-pugleaf

In article <816@Diamond.BBN.COM> mlandau@slate.BBN.COM (Matt Landau) writes:
>
>There was a very interesting presentation at this year's Summer Usenix
>on communicating data between processes in different windows existing
>in a graphical user environment.  It was called "A Data-Flow Manager for
>an Interactive Programming Environment", and was given by Paul Haeberli
>of Silicon Graphics.  The accompanying paper may be found in your local
>copy of the 1986 Summer Usenix Proceedings.  The system amounted to a
>way to pipe data between graphical manipulation and display programs, and
>provided a user-interface that made specifications of input and output 
>sources easy (lines and arrows, etc.)

The great thing about this is that it allowed you to set up arbitrary
data-flow graphs, not just pipes.  This is important for interconnecting
3D graphics tools, since one program may have several "inputs".

What it does *not* do is allow you to set up a straight pipeline, the most
common form of parallelism in UNIX, as fast as just typing '|'.

One of the nice things about UNIX is the rapidity with which you can
put together "paste x y z | egrep pattern | sort | awk 'commands'".
To do this while staying in the MAC user interface model would require
that the shell be made into a graphics program, with some sort of
graphical way of building all of the constructs that you can currently do
with a command line.

Now, a graphical tool for building pipelines isn't too hard to imagine.
But the shell (any of them) is actually a quite powerful programming
language, and I find it hard to imagine a graphical tool with all the
flexibility of the shell (loops, conditionals, background processes,
argument processing) that would not be incredibly clumsy to use, just
because of all the possible choices.

So, a question:  If you had the best programming team in the world
available, able to implement any consistent design you came up with,
how *would* you design a shell?