pfeiffer@nmsu.edu (Joe Pfeiffer) (11/15/90)
In article <1990Nov13.211634.28152@batcomputer.tn.cornell.edu> andyrose@batcomputer.tn.cornell.edu (Andy Rose) writes:
Craig Upson asks "does the 'visual programming' paradigm work?"
The visual programming paradigm is a perhaps recent development. It
basically refers to the ability to prototype code by "dragging" or
manipulating icons which represent functional modules on a "palette"
or workspace. Each icon has inputs and outputs. In AVS they are
represented as colored bars on the top and bottom of a rectangle which
contains the name of the module. The colors represent the type of data
which is needed or produced. In apE the icon is a picture and the name
can be displayed by pressing the middle button while in the icon. I
like the text approach better because of the difficulty of designing
meaningful ideograms for hundreds of modules.
The modules are "hooked together" using mouse interaction. In AVS
the user placed the mouse on an output color bar and holds a button down.
All the legal connections are displayed and the user moves the mouse to
highlight the one he needs. Disconnects are handled similarly.
The hooks, or "pipes" are color coded in AVS to indicate data type.
<excellent comments on visual programming deleted>
While everything Andy says is true, it is important to note that
what he describes is not ``all'' of visual programming. It is,
rather, a member of a subclass I like to refer to as data flow visual
programming; other members of the subclass include Petri net
programming and state machine programming. One writes a program by
developing a data structure of some sort on the screen, and having
tokens flow between the elements of the structure.
More generally, visual programming refers to an environment where the
spatial relationship of objects on the screen describes an algorithm;
I'm working on an environment using graph grammars for data structure
manipulation, for example. It is possible for the perverse to make an
argument that textual languages fit this definition; this is not true
because the meaning of the position of symbols in a textual language
is one-dimensional. Languages where indentation level is significant
(such as Occam) start to fit this definition, but they are
abominations.
We now return you to your regularly scheduled discussion of
visualization. I've crossposted this to comp.lang.visual, and
directed followups there. I will also retire to my closet for my
asbestos suit, since I expect I'll be hearing from both Occam
supporters soon.
-Joe.