🚀 go-pugleaf

In article <2356@cbnewsj.ATT.COM> jwi@cbnewsj.ATT.COM (Jim Winer @ AT&T, Middletown, NJ) writes:
>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
ucsd!celerity!dave or dave@fps.com
"Repent, Harlequin!," said the TickTock Man