metaphor and programming 
Author Message
 metaphor and programming

Here is something new to argue about.

thesis 1) we humans in large part structure our thinking about problems by
reformulating them in a manner consistent with real-world experience, and
then use our real world knowledge to drive our intuition about problems.
To put it briefly, we use metaphors.

thesis 2) radical changes in programming languages occur when new
metaphors are introduced.  (witness logic programming, witness object
oriented programming).

What do I mean by metaphors?  Here is a partial list.
I would welcome any additions (particularly given my note at the end).

1. The process-state, or pigeon-hole metaphor.  Computation is based
around the idea of slots that can hold values.  Algorithms are directed
towards the proper accessing of the right slots at the right times.
        examples: Algol-like languages, spreadsheets.
        real world experiences that help us intuit about the model:
                collating, sorting of any sort, (and of course mailpersons?)

2. The flow model.  Computation is modeled on a flow of data being directed
and modified over space.  Programming is the process of putting together
conduits for flow in different forms.
        experiences: electronic circuits, water pipes, tinker toys,
        examples: data flow languages, functional languages.

3. The autonomous agent model.  Programming is modeled on a delegation of
responsibility to a variety of more or less autonomous agents.  Computation
involves setting up the agents, and then having them interact.
        experiences: most real world interactions
        examples: object oriented languages

4. The sample catalogue model.  Not really a model of computation, but
related.  Purpose is to display information to the user in an easily
indexiable form.  Information is more or less fixed, programming involves
establishing access patterns.
        experiences: catalogues, dictionaries, other references.
        examples: hypercard, rapid prototyping systems.

5. The declarative, or inference model.  Programming consists of writing
lists of facts and rules of inference.  Computation involves the answering
of queries.
        experiences: geometry, logic
        examples: prolog, other declarative systems.

6. The learning model.  Programming consists of showing a number of
examples of a specific pattern to a learning system, which infers a general
rule.
        experiences: human learning
        examples: AI learning systems.

Now on to my thesis 3.  I have observed that visual programming, that is
programming in a visual manner, has not been as successful as one might
have hoped.  At first, the common thought is ``people are basically
visual'', or ``a picture is worth 1,000 words''.  But actual visual
languages tend to be either (1) hard to use, (2) fun, but no more
productive than conventional languages, or (3) limited to very narrow
domains.  We don't have a general purpose language of the flexibility,
power, and ease of use of say Pascal.

My thesis is that this is so because the metaphors we are using are
basically not visually oriented to start with, and forcing them to be so
necessarily results in the problems I mention.

New languages, and in particular new visual languages, will require a
totally new metaphor for what it means to compute.

No, I don't have any suggestions.  I can say that, however, that the new
metaphor if it is to be successful must appeal to some innate, or at least
common, well of experience within us.  Just as I believe the object
oriented philosophy strikes a responsive cord in people (particularly those
not already brainwashed into other modes of thinking) because it appeals to
experience.

(metacomment:  I prefer the term ``metaphor'' to ``paradigm'', because I
think most individuals have an intuition about metaphors that is close
to the sense in which I am using the term).



Mon, 19 Apr 1993 23:17:00 GMT  
 metaphor and programming

Quote:

>[order of presentation reversed - near end of article, Tim says]
>My thesis is that this is so because the metaphors we are using are
>basically not visually oriented to start with, and forcing them to be so
>necessarily results in the problems I mention.

>New languages, and in particular new visual languages, will require a
>totally new metaphor for what it means to compute.
>[near beginning, Tim says]

>thesis 2) radical changes in programming languages occur when new
>metaphors are introduced.  (witness logic programming, witness object
>oriented programming).

>What do I mean by metaphors?  Here is a partial list.
>I would welcome any additions (particularly given my note at the end).

>2. The flow model.  Computation is modeled on a flow of data being directed
>and modified over space.  Programming is the process of putting together
>conduits for flow in different forms.
>    experiences: electronic circuits, water pipes, tinker toys,
>    examples: data flow languages, functional languages.

Are you saying that this is not a visually-oriented metaphor?  All
reasoning in all of those "experiences" you mention starts with the
eyes.  The problem with visually presenting a data flow or functional
program is the complexity.  Software design almost always starts out
with some type of dataflow diagram.  I have been to workshops where
everyone is to present solutions to a common problem, and virtually
every presenter had a slide with a DFD of the high-level program design,
no matter what language or form the final program was implemented in.
But you don't see many flowcharts anymore - the complexity cross-over
point is somewhere between these two.

So, my claim here is that the metaphor isn't bad, but we shouldn't
apply it to things that can be better represented using other methods.

Quote:
>3. The autonomous agent model.  Programming is modeled on a delegation of
>responsibility to a variety of more or less autonomous agents.  Computation
>involves setting up the agents, and then having them interact.
>    experiences: most real world interactions
>    examples: object oriented languages

The only reason that such agents are considered "autonomous" is that
their interaction is not usually visualized!  If it was, we could
see the relationships between those agents currently communication and
those that are able to communicate, and would think of them as anything
but autonomous.  (This is not to say that such "objects" cannot often be
reasoned about separately when a system is being designed.)

Quote:
>5. The declarative, or inference model.  Programming consists of writing
>lists of facts and rules of inference.  Computation involves the answering
>of queries.
>    experiences: geometry, logic
>    examples: prolog, other declarative systems.

Logic also has a visual component - a proof is a DAG, where the vertices
are true propositions and edges are inference rules.  Also, if we make the
correspondence between the truth of a proposition and the presence of
a value for a single-assignment variable, dataflow and logic start looking
similar.

Quote:
>Now on to my thesis 3.  I have observed that visual programming, that is
>programming in a visual manner, has not been as successful as one might
>have hoped.  At first, the common thought is ``people are basically
>visual'', or ``a picture is worth 1,000 words''.  But actual visual
>languages tend to be either (1) hard to use, (2) fun, but no more
>productive than conventional languages, or (3) limited to very narrow
>domains.  We don't have a general purpose language of the flexibility,
>power, and ease of use of say Pascal.

Fred ("No silver bullet") Brooks makes the claim that programs are much
more complex than VLSI, and its erroneous to think that we can use the
same graphical approaches for both [gross oversimplification].  So, let's
hide the complexity (where we must) inside programs written with standard
textual languages, and leave only the interactions between these programs
out where they can be seen.

A.  Visual languages will only be used where they offer some leverage -
  at the level of process interaction.  Below that, each "actor" can be
  considered to execute some atomic action that is more easily understood
  in some other more compact and appropriate form.

B.  At this high level, we should have more power than the dataflow
  metaphor gives us.  By combining standard dataflow principles with
  those of Petri nets and finite state machines, update-in-place and
  controlled non-determinism can be expressed quite naturally.  

C.  Just because a language is visual doesn't mean that it doesn't
  require a programmer to think through the problem and precisely
  express the solution.  Thus, "Hard to use" is only a problem if it's
  "harder to use" than other solutions, and if the difficulty lies with
  the language itself and not the interface.

We have been working on developing a language, LGDF2*, for some time now,
and though I have customized both the textual and graphical syntax of the
language to suit my tastes, I ALWAYS find myself writing programs in it
graphically.  (Now if I can just find someone to implement a nice graphical
interface for it ...)

Dave

* LGDF2 = Large-Grain Data Flow, see HICSS-21 or COMPCON89



Mon, 19 Apr 1993 01:47:00 GMT  
 metaphor and programming



        >>[order of presentation reversed - near end of article, Tim says]

        >>My thesis is that this is so because the metaphors we are using are
        >>basically not visually oriented to start with, and forcing them to be so
        >>necessarily results in the problems I mention.

        >>[near beginning, Tim says]
        >>
        >>thesis 2) radical changes in programming languages occur when new
        >>metaphors are introduced.  (witness logic programming, witness object
        >>oriented programming).
        >>
        >>What do I mean by metaphors?  Here is a partial list.
        >>I would welcome any additions (particularly given my note at the end).
        >>
        >>2. The flow model.  Computation is modeled on a flow of data being directed
        >>and modified over space.  Programming is the process of putting together
        >>conduits for flow in different forms.
        >>        experiences: electronic circuits, water pipes, tinker toys,
        >>        examples: data flow languages, functional languages.
        >>
        >Are you saying that this is not a visually-oriented metaphor?  All
        >reasoning in all of those "experiences" you mention starts with the
        >eyes.  The problem with visually presenting a data flow or functional

        [.. dataflow diagrams and presentations etc...]

        >So, my claim here is that the metaphor isn't bad, but we shouldn't
        >apply it to things that can be better represented using other methods.

I would think that the design phase where you really use the metaphors
is not so visual, or precisely experienced through the eyes. It is
more of a consolidation and presentation time thing.
        The thing with metaphors is that they help you to structure
the associations in your mind. (I am not quite able to put this in words)
And do it better than diagrams.

        >>3. The autonomous agent model.  Programming is modeled on a delegation of
        >>responsibility to a variety of more or less autonomous agents.  Computation
        >>involves setting up the agents, and then having them interact.
        >>        experiences: most real world interactions
        >>        examples: object oriented languages
        >>

        >The only reason that such agents are considered "autonomous" is that
        >their interaction is not usually visualized!  If it was, we could

The autonomy is in the density of interactions within and between
objects. Also that they are a semantic unit.

The visualisation idea here would work in the form of painting.
We need icons which can be composed as easily as a painter puts
together images of natural objects.Making a landscape out of mountains,trees
sky and clouds.

        >>5. The declarative, or inference model.  Programming consists of writing
        >>lists of facts and rules of inference.  Computation involves the answering
        >>of queries.
        >>        experiences: geometry, logic
        >>        examples: prolog, other declarative systems.
        >>

        >Logic also has a visual component - a proof is a DAG, where the vertices
        >are true propositions and edges are inference rules.  Also, if we make the

Such a dag is perhaps too complex to be of any use visually.

        >>Now on to my thesis 3.  I have observed that visual programming, that is
        >>programming in a visual manner, has not been as successful as one might
        >>have hoped.  At first, the common thought is ``people are basically
        >>visual'', or ``a picture is worth 1,000 words''.  But actual visual
        >>languages tend to be either (1) hard to use, (2) fun, but no more
        >>productive than conventional languages, or (3) limited to very narrow
        >>domains.  We don't have a general purpose language of the flexibility,
        >>power, and ease of use of say Pascal.
        >>
        >hide the complexity (where we must) inside programs written with standard
        >textual languages, and leave only the interactions between these programs
        >out where they can be seen.

        >and though I have customized both the textual and graphical syntax of the
        >language to suit my tastes, I ALWAYS find myself writing programs in it
        >graphically.  (Now if I can just find someone to implement a nice graphical
        >Dave

I agree. At some level, the visualisation must stop. To use the painting
metaphor (See what I said about metaphors ;-) at some level you are left
with strokes of paints, not object representations.

I would also like to add, I don't think in writing functional programs
we think of data flow as such. It is more a composition, a algebraic
formula approach. This is nice because we learn a lot to think like
that in maths.
I do think visually while solving problems, but more often it is a case of
Oh! this formula fits!.

(Disclaimer : I am not someone working in visual programming, or
functional. I just thought this discussion was interesting. So please
point out any bloomers, or repititions of ideas well known to experts
who might be reading this. (eg "painting"))

Aamod Sane



Mon, 19 Apr 1993 06:38:00 GMT  
 metaphor and programming
Rather than citing specifics in previous articles on this subject, I'm going
to outline where I am coming from - parallel computation, and more generally,
parallel software engineering.  Functional (and dataflow) approaches have
been used in this arena for decades, but they have drawbacks which, in my
opinion, are caused by restricting the expression of functional composition
to a left-to-right textual string.

Drawback 1.  Functions return a single result.
    There is nothing hard about formalizing functions which return more
    than one result, and in fact, it is not hard to express such a function
    "call" in a textual fashion - consider a call to a routine (without side-
    effects) which alters the values of some of its arguments.  The problem
    comes in when trying to compose such functions.  Such a composition
    can simply not be expressed clearly in the linear, left-to-write
    fashion that we use when writing text.  Pictures handle this nicely,
    though.

Drawback 2.  Functions cannot specify in-out parameters
    Dataflow and Functional languages typically rely on single-assignment
    (or "zero-assignment") variables, tossing out the notion of "updating"
    an argument in place.  Again, it is not hard to formalize a form of
    function which allows this - consider Modula, etc, which declare
    routine arguments as in, out, or inout.  But even with a graphical form
    of composition addressing drawback 1, above, this adds new problems to
    composition.  A function can no longer simply await its "in" arguments
    before evaluating - a means of moving these inout arguments from one
    function evaluation to the next in an orderly fashion must be developed.
    Petri nets give us one model of how this can be done, by considering
    places as having a spot which can hold data which is completely
    independent of its token state, and each process has in, out, or inout
    permission to each of its places.

Drawback 3.  Indeterminacy, non-determinism
   (Although these actually mean different things, I will mis-use both to
   mean that the results of a computation may depend on timing relationships
   as well as its input data.)  In standard functional composition, the
   composition of two functions is another function.  Parallel programs which
   exhibit non-determinism are not functional.  Thus, if we assume that such
   programs should be expressible (which I wholeheartedly believe), a more
   powerful form of composition is needed.  Though tossing "oracle functions"
   and merge operations into functional and dataflow languages will sometimes
   suffice, I prefer a more natural one which says "hey, this result is
   up for grabs to the first function (on some list) that can evaluate with
   it".  Petri nets again give us this framework.

So, do the gains of using such a graphical representation balance the
losses?  In this world, one expresses their program graphically as this
petri-net-like network of functions (called an F-Net), then implements the
functions in their favorite language.  The individual functions are
essentially subroutines, except that they cannot maintain internal state
between invocations, and they explicitly declare when each of their return
values is ready.  They are not susceptible to the usual "parallel" problems -
from the programmer's point of view, each such function runs completely
independently, alone, and atomically, so their arguments will not change
out from under them.  These functions are never called explicitly,
but implicitly according to the current "token state" of its arguments
in the composition diagram (F-Net).

This brings me back to my initial point.  Stuff that can be better expressed
in a textual language (i.e. classical deterministic functional composition
of functions returning single results) should be expressed in such languages,
but a graphical language allows some freedom when this proves too restricting.

I would be interested in hearing criticisms of this approach.  For more
info, see COMPCON Spring 89 proceedings.  (With luck, I may have
something more up-to-date accepted soon.  Then there's my dissertation...
someday)

Dave

--
David C. DiNucci          Oregon Graduate Institution of Science & Tech.
                                       (Formerly Oregon Graduate Center)

UUCP:  ..ucbvax!tektronix!ogccse!dinucci      Beaverton, Oregon  97006



Mon, 19 Apr 1993 18:38:00 GMT  
 metaphor and programming
You know, a case could be made that a spreadhseet *is* a visual programming
language.

I think visual languages would be most closely related to the dataflow
metaphor. That is the most dimensionally ordered one. Think of building
UNIX shell programs by fitting together pipes to little tanks called
"awk" and "sed"...

But visual programming generally seems to be concentrated on database
type things, expressed by turning a relation into a tree. The problem is
that this tree is essentially linear: people don't need the extra
dimension to comprehend it. In fact the 2-d representation conflicts
with the 1-d representation of trees we're taught in school: algebraic
notation.

Perhaps a visual shell for UNIX would be a useful place to start.
--

 'U`  --------------  +1 713 274 5180.
"vi is bad because it didn't work after I put jelly in my keyboard."



Mon, 19 Apr 1993 15:20:00 GMT  
 metaphor and programming

Quote:
>I think visual languages would be most closely related to the dataflow
>metaphor. That is the most dimensionally ordered one. Think of building
>UNIX shell programs by fitting together pipes to little tanks called
>"awk" and "sed"...

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.

The visual programming system I have worked on, SunPict, views programs
procedurally, mapping program statements to icons on the screen.  I
think that this control flow visualization adds much more to the
understanding of programs.  Control flow is obviously not only
one-dimensional.  Between conditional statements and function calls,
a two (or more) dimensional mapping adds a lot.

Dave "mr question" McIntyre     |      "....say you're thinking about a plate

office : 518-276-8633           |       you `plate,' or `shrimp'......"
home   : 518-271-6664           |



Mon, 19 Apr 1993 04:08:00 GMT  
 metaphor and programming

" You know, a case could be made that a spreadhseet *is* a visual programming
" language. ...

Don't forget Adventure -- a type of program people love to write
and use.  Natural language interface.  Dynamic linking and
unlinking (`pick up knapsack' ...).  Variable information
hiding as a function of the state of computation (`look').
Autonomous agents. ...



Mon, 19 Apr 1993 13:55:00 GMT  
 metaphor and programming

->I think visual languages would be most closely related to the dataflow
->metaphor. That is the most dimensionally ordered one. Think of building
->UNIX shell programs by fitting together pipes to little tanks called
->"awk" and "sed"...
->
-
-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.
-
-[...]

The one-dimensionality is only a restriction of the conventional
UNIX command interpreters ("shells"), not of pipes as such.
See the article of McDonald and Dix
in Software - Practice and Experience (October 1988).
It describes a "graph shell" (gsh) that allows arbitrary networks
of pipes to be constructed.
However, most standard UNIX programmes have been designed with
one input and at most two outputs, so the potential advantages
of a graph shell cannot be fully exploited with them.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland



Mon, 19 Apr 1993 14:19:00 GMT  
 metaphor and programming
I'm having a slight problem with the metaphor here -- a visual
situation is highly parallel and essentially instantaneous or static.
A procedure that processes anything exists in time. The only area
of overlap with the visual seems to be in terms of perceived motion
within the visual field. Thus, a visual programming language must
be either verbal (describing motion within the visual field) or
kinesthetic (physically moving something within the visual field).
(A third possibility is changing the field, but that seems verbal
or kinesthetic also.)

This seems to lead to three types of models:

1. Something like the Mac interface of the HP NewWave program where a
file is printed by clicking on its folder and moved to the printer icon,
or a file is deleted by clicking on its folder and moving it to the
waste basket.

2. A verbal procedural language with directives for camera control (truck,
tilt, pan, zoom, crop, etc.) and for object manipulation (select, move,
etc.). This corresponds to most flight simulators and to some virtual
reality systems.

3. Pattern recognition systems that classify objects, but are essentially
passive. (Any action is the result of the classficiation, not the
recognition system.) Neural nets are the most common example.

All of these types of systems exist. Yet I get the impression from this
discussion that someone wants a new metaphor that is more related to
visual processing, and thinks that this will result in a "break through"
in programming or processing technology. I don't understand what else
visual processing involves that is not included in one of these
existing systems.

Jim Winer -- The opinions expressed here are not necessarily
             and do not represent nor in any way imply
             of any other sane person and especially not
             employer.
"My reply is that such pre-theoretical conceptual essences are often
riddled with deep ambiguity and internal incoherence, despite strong
convictions people have that they know what they mean." -- Aaron Sloman



Mon, 19 Apr 1993 14:48:00 GMT  
 metaphor and programming
You might want to check out Neil Postman's "Teaching as a Conserving
Activity" in which he contrasts the curriculums offered by TV and
Schools (or what schools should offer).  In it he spends a fair amount
of time contrasting static (books) and dynamic (tv) visual media. He
says many standard things, but says them so well.

Rich Pattis



Mon, 19 Apr 1993 17:23:00 GMT  
 metaphor and programming

Quote:


>>I think visual languages would be most closely related to the dataflow
>>metaphor. That is the most dimensionally ordered one. Think of building
>>UNIX shell programs by fitting together pipes to little tanks called
>>"awk" and "sed"...

>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.

Unix pipe programs are one dimensional because they're limited by the shells
to be one dimensional.  There's no reason why they couldn't be two
dimensional and there's been more than one time when I'd have liked one
to be.  For example, you have a pipe that produces a stream of data that
you need to do two different transformations on, say get the first field
and get the second field.  Normally we do:

        producer_prog | sed | grep > /tmp/foo

        awk 'control string 1' < /tmp/foo > x1
        awk 'control string 2' < /tmp/foo > x2

I'd prefer to skip the temporary file and just do:

                                    /-awk 'control string 1' > x1
        producer_prog | sed | grep <
                                    \-awk 'control string 2' > x2

The other thing that would be quite nice would be to have more than one
input to a program be a pipe, so you wouldn't have to do:

        pipe1 > /tmp/foo
        pipe2 | diff /tmp/foo

        but instead:

        pipe1 -\
                > diff
        pipe2 -/

Once you've got this dataflow shell, scaling it up and adding features to it
to make it a full-fledged language wouldn't be too hard.  One of these days...

--
David L. Smith
FPS Computing, San Diego

"Repent, Harlequin!," said the TickTock Man



Mon, 19 Apr 1993 17:49:00 GMT  
 metaphor and programming
[ I suggested that dataflow languages, like the UNIX pipes, are best adapted
  to visual languages ]

Quote:
> 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.

Unfortunately, it isn't. I frequently want to combine data in more complex
ways, and are reduced to using temp files or makeshifts like !(shell | tee
/dev/stdout 1>&2 | ... ) | something else!

Here's a stripped down version of something recently posted to the net:

Quote:
> doc=/tmp/splchk.$$
> scr=/tmp/sedscr.$$
> cat $args > $doc
> cat > $scr <<HEAD
> s/^/ /
> s/\$/ /
> HEAD
> spell $spellflags < $doc | sed -e "\
>    s/^/s;\\\\([    ][^a-zA-Z0-9]*\\\\)\\\\(/
>    s/\$/\\\\)\\\\([^a-zA-Z0-9]*[   ]\\\\);\\\\1${T1}\\\\2${T2}\\\\3;g/
>    s/ \$//" >> $scr
> cat >> $scr <<TAIL
> s/^ //
> s/ \$//
> TAIL
> sed -f $scr $doc
> rm -f $doc $scr

Now that 'sed' at the end takes two input streams, one is a command
stream from $scr, and the other is the contents of a set of files in $doc.

Visually, this would be something like:
              .--C> cat ------v
args --> tee <           .-C> sed --> output
              `---> sed -'
Where C> means the command input of the program. Using a 2-d visual
language this sort of thing becomes easy.

Quote:
> The visual programming system I have worked on, SunPict, views programs
> procedurally, mapping program statements to icons on the screen.  I
> think that this control flow visualization adds much more to the
> understanding of programs.

That's a perfectly good format for dealing with procedural languages. As
is the conventional linear format. On the other hand, there really isn't
a good linear format for dataflow languages...
--

 'U`  --------------  +1 713 274 5180.
"vi is bad because it didn't work after I put jelly in my keyboard."



Mon, 19 Apr 1993 18:17:00 GMT  
 metaphor and programming

Quote:
>I'm having a slight problem with the metaphor here -- a visual
>situation is highly parallel and essentially instantaneous or static.
>A procedure that processes anything exists in time. The only area
>of overlap with the visual seems to be in terms of perceived motion
>within the visual field. Thus, a visual programming language must
>be either verbal (describing motion within the visual field) or
>kinesthetic (physically moving something within the visual field).
>(A third possibility is changing the field, but that seems verbal
>or kinesthetic also.)

The model I'm thinking of, and the one I see being discussed here most often,
is a graphical, as opposed to textual, description of instruction or
data flow, i.e. a flow chart, or data-flow diagram.

Data flow languages seem to map quite easily and naturally into graphs.  I'm
interested in data flow because it allows for easy parallelism; the data
dependencies are automatically spelled out and instruction scheduling is
left as a (simple) task for the compiler.

--
David L. Smith
FPS Computing, San Diego

"Repent, Harlequin!," said the TickTock Man



Mon, 19 Apr 1993 23:19:00 GMT  
 metaphor and programming

Quote:

> Unix pipe programs are one dimensional because they're limited by the shells
> to be one dimensional.   [...]
> I'd prefer to [..do something like..]:
>                                /-awk 'control string 1' > x1
>    producer_prog | sed | grep <
>                                \-awk 'control string 2' > x2

This particular trick can actually be done with the bourne shell as it
currently exists.  Of course, just arbitrarily drawing two dataflows out
of the grep doesn't make the program capable of producing two
datastreams.  We would have to get used to more "pipe fitting" programs
or switches to existing programs.  I'll ignore that, and produce just
the example above:

   producer_prog|sed|(grep|awk 's1' >x1&) 3>&1 | awk 's2' >x2

(This is, of course, asuming that "grep" produces one datastream
 on descriptor 1, and another on descriptor 3.)

Quote:
> The other thing that would be quite nice would be to have more than one
> input to a program be a pipe [..like..]
>    pipe1 -\
>            > diff
>    pipe2 -/

This, too, is possible in the bourne shell off-the-shelf.  Again, it is
necessary to suppose that diff can take two input streams, and so this
would require a variant of diff, or an additional switch to diff.  But
be that as it may:

      pipe1 | (pipe2 | diff) 3<&0

(This is assuming that "diff" will take an additional input on f.d. 3.)

Quote:
> Once you've got this dataflow shell, scaling it up and adding features to it
> to make it a full-fledged language wouldn't be too hard.  One of these days...

Well, ugly as the bourne shell syntax for these things is, and limited
as it is (it can't for example produce two dataflows between just two
processes, nor a circular dataflow, nor many others), it IS ALREADY a
start.  Why not start using it, and expand on it by writing pipe
fittings as needed, like the "split" option of grep, or the "join"
option of diff, and others? Then, when a fancy graphical user interface
with allows for multiple data flows into and out of programs occurs, the
primitives necessary to using it will already exist.

(Another very interesting "pipe fitting" program is one that will
 produce named pipes in the file system.  That way, programs which
 require filenames (such as diff) can be put into a pipe.  The above
 examples might be done like so with two primitives:
         ... |psplit "grep e1|awk 's1' >x1" "grep e2|awk 's2' >x2"
         pjoin f1 "pipe1" f2 "pipe2" "diff $f1 $f2" | ...
 Once you've written psplit and pjoin, you can do a lot, fairly nicely.
 Further, a graphical dataflow program could be trained to use them to
 produce the various fittings in the dataflow, while using existing
 unix tools as the nodes. )

In any event, if one really wants to exploit complicated pipe dataflows,
the thing to do is just go ahead and do it something like the way outlined
above.  Waiting for neat graphical-oriented dataflow shells to become
widely available just hasn't worked for me in the past... this has.
--



Mon, 19 Apr 1993 21:36:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Programming Metaphors

2. Design by Metaphor

3. what is the best metaphor for this?

4. Looking for Killer Metaphor

5. Mixed Metaphors (Was: Are Forth Chips RISCs?)

6. Metaphor Revisited

7. LOGO-L> Spatial metaphor for Superturtle

8. Oberon windows metaphor shift.

9. Great metaphor

10. L4: Lifestreams, Living Metaphor, Linda on the Web, LISP

11. replacing the desktop metaphor

12. Tool-Material-Metaphor

 

 
Powered by phpBB® Forum Software