Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!unmvax!ariel.unm.edu!nmsu!opus!pfeiffer From: pfeiffer@nmsu.edu (Joe Pfeiffer) Newsgroups: comp.graphics.visualization,comp.lang.visual Subject: Re: Requirements? Message-ID: Date: 15 Nov 90 15:57:41 GMT References: <1990Nov13.211634.28152@batcomputer.tn.cornell.edu> Sender: news@NMSU.Edu Followup-To: comp.lang.visual Organization: NMSU Computer Science Lines: 48 In-reply-to: andyrose@batcomputer.tn.cornell.edu's message of 13 Nov 90 21:16:34 GMT 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. 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.