Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-sdd!ucsdhub!celit!dave
From: dave@fps.com (Dave Smith)
Newsgroups: comp.lang.visual,comp.lang.misc
Subject: Re: metaphor and programming
Message-ID: <3930@celit.fps.com>
Date: 17 Nov 89 23:19:48 GMT
References: <13770@orstcs.CS.ORST.EDU> <7000@ficc.uu.net> <1989Nov17.040858.22886@rpi.edu> <2356@cbnewsj.ATT.COM>
Sender: daemon@fps.com
Reply-To: dave@fps.com (Dave Smith)
Followup-To: comp.lang.visual
Organization: FPS Computing Inc., San Diego CA
Lines: 27

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