budd@mist.CS.ORST.EDU (Tim Budd) (11/15/89)
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).
dinucci@ogccse.ogc.edu (David C. DiNucci) (11/15/89)
In article <13770@orstcs.CS.ORST.EDU> budd@mist.CS.ORST.EDU (Tim Budd) writes: >[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. >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.) >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. >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
sane@brutus.cs.uiuc.edu (Aamod Sane) (11/15/89)
dinucci@ogccse.ogc.edu (David C. DiNucci) writes: >In article <13770@orstcs.CS.ORST.EDU> budd@mist.CS.ORST.EDU (Tim Budd) writes: >>[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
dinucci@ogccse.ogc.edu (David C. DiNucci) (11/16/89)
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)
CSNET: dinucci@cse.ogc.edu 19600 N.W. Von Neumann Dr.
UUCP: ..ucbvax!tektronix!ogccse!dinucci Beaverton, Oregon 97006peter@ficc.uu.net (Peter da Silva) (11/16/89)
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. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "vi is bad because it didn't work after I put jelly in my keyboard." -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)
mcintyre@turing.cs.rpi.edu (David McIntyre) (11/17/89)
In article <7000@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >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 mcintyre@turing.cs.rpi.edu | of shrimp.....and someone says to office : 518-276-8633 | you `plate,' or `shrimp'......" home : 518-271-6664 |
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (11/17/89)
From article <7000@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): " 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. ... Greg, lee@uhccux.uhcc.hawaii.edu
sakkinen@tukki.jyu.fi (Markku Sakkinen) (11/17/89)
In article <1989Nov17.040858.22886@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes: -In article <7000@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: ->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
jwi@cbnewsj.ATT.COM (Jim Winer @ AT&T, Middletown, NJ) (11/17/89)
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
pattis@cs.washington.edu (Richard Pattis) (11/18/89)
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
dave@fps.com (Dave Smith) (11/18/89)
In article <1989Nov17.040858.22886@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes: >In article <7000@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>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 ucsd!celerity!dave or dave@fps.com "Repent, Harlequin!," said the TickTock Man
peter@ficc.uu.net (Peter da Silva) (11/18/89)
[ I suggested that dataflow languages, like the UNIX pipes, are best adapted to visual languages ] > 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: > 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. > 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... -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "vi is bad because it didn't work after I put jelly in my keyboard." -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)
dave@fps.com (Dave Smith) (11/18/89)
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
crm@romeo.cs.duke.edu (Charlie Martin) (11/23/89)
In article <13770@orstcs.CS.ORST.EDU>, budd@mist.CS.ORST.EDU (Tim Budd) writes: > 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). > > ... > 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. > Funny you should mention this. Appended is an extract from Chapter 1 of my dissertation. The dissertation is basically two topics: representing large systems for computer-aided engineering, and then using these results to build a visual programming environment specific to physiological simulation. My reasoning about visual programming has pretty much exactly duplicated the above. I think the reason visual programming hasn't paid off is that our visual programming notations (or metaphors) are not cognitively more powerful than the textual notations we already use. (This is basically the contrapositive of the "No Silver Bullet" argument -- if the difficulties of programming are essential to the nature of programming, and the essential nature of programming is such that there is not much more room for gain, then bigger gains must come from changes to the nature of programming.) I don't know how to make a better general programming notation; but I think that spread sheets offer an example of a better notation LIMITED TO A SMALL PROBLEM DOMAIN. It think the extract states some of my reasoning. (If anyone wants to read the rest of the dissertation, you'll have to wait until I've finished typing the thing. Maybe end of January.) \section{Computer Aided Exploratory Programming} Most people who use computers use them as a means to an end, rather than as an end in themselves. These people usually find it hard to specify what they need; it takes a long time to build what they have specified; and it is hard to be certain that what they get correctly does what was specified. These problems --- specification, construction, correctness --- are the conventional problems of software engineering. Software engineering methods have addressed these problems successfully in certain cases, particularly when firm specifications can be established and left unchanged until delivery of the system or program. Physiologists and others in the experimental sciences can use computers effectively in research, and in some areas now {\em must\/} use computers to pursue interesting research, but their use of computers doesn't fit conventional methods of development. Their programs often do not need to perform the same calculations for a long time; instead, their programs change rapidly as a model of some physical system is built and tested. Once the model of the physical system is validated sufficiently, the program is either discarded or used as a basis for further development of more complex models. In effect, these programs have no operational phase in their lifetimes. The desired result is not a productive computer program, but a validated specification of the computation, and thus a validated model of the physical system. This style of use can be termed {\em exploratory programming\/}. Exploratory programming presents a number of special problems. Many scientists, especially in the biological sciences, are neither skilled programmers nor mathematically sophisticated. For these scientists, the problems of specification, construction, and correctness can be overcome only by devoting time and effort to developing the skills and sophistication required, or by obtaining the services of someone with the needed skills. A computer capable of sophisticated physiological modeling can be purchased for less than \$2000; this is comparable to the cost of a programmer's services for just one week. The cost of programming effort, not the cost of computation, is the major limit to the use of computers in physiology. Another area in which exploratory programming is common is in accounting. Spread sheet programs such as Lotus~1-2-3 are used to build active financial models which can be used experimentally. Spread sheets provide accountants and financial users with a computer aided programming environment with a user interface specific to their particular problem area. The user directly manipulates the form of the model --- and thus the specification of a program --- and constructs the program itself directly from this specification. This can be termed {\em domain specific programming\/}: programming in which the programming language or notations is based on a limited model of problems which is specific to the particular problem domain. The {\em Model Definition Environment\/} (MDE), is a domain-specific programming tool which provides physiologists a visual programming notation for describing a physiological system. From the user's point of view, it is an environment for scientific exploratory programming with some of the same advantages that spread sheets offer for accounting. However, unlike commercial spread sheet programs, MDE is wholly retargetable. With the large system representation at its core, new visual programming interfaces and new execution ``back ends'' can be added as desired. The same architecture could be used to implement many different domain-specific programming environments. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
crm@romeo.cs.duke.edu (Charlie Martin) (11/23/89)
On second thought, maybe it wasn't so clear. The rest of the idea is that these notations for domain-specific exploratory programming need to be drawn from the metaphors already in use, such as in physiology the metaphors or notations of compartmental models and kinetic diagrams. By building the notations around the metaphors that are already commonly used, we use the user's knowledge of their own domain to validate the form of the models or programs. They have accumulated skills and techniques which they (automatically or as part of standard practice) apply to the definition of the problem using the notation. Sorry for the lack, I've been working on this &$^#%^@ dissertation for so long I no longer remember my name.... . see, now I think I'm using ed.... Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
salomon@ccu.umanitoba.ca (Dan Salomon) (11/24/89)
In article <1989Nov17.040858.22886@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes: >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. That's the whole point: UNIX pipes are one dimensional because they have to be represented in text. By having a visual shell you could have two dimensional pipes. A few TEE programs have been written, that let you send the same output two places at once, but multiple standard inputs & outputs would be more useful. For example you may want to take an input file and a stream of update commands (two standard inputs), pipe command errors to the terminal, a modification list to the printer, and an updated file to a post-processing consistency checker (three standard outputs). One of the reasons that UNIX compilers don't provide source listings with embedded error messages, is that this would require two standard outputs, one for the listing and one for the task image.
reggie@dinsdale.nm.paradyne.com (George W. Leach) (11/28/89)
In article <1989Nov23.162521.4022@ccu.umanitoba.ca> salomon@ccu.UManitoba.CA (Dan Salomon) writes: >That's the whole point: UNIX pipes are one dimensional because >they have to be represented in text. By having a visual shell >you could have two dimensional pipes. It is the shell that is one dimensional, not the pipe. >A few TEE programs have been written, that let you send the same output >two places at once, but multiple standard inputs & outputs would be >more useful. For example you may want to take an input file and a >stream of update commands (two standard inputs), pipe command errors to >the terminal, a modification list to the printer, and an updated file >to a post-processing consistency checker (three standard outputs). One >of the reasons that UNIX compilers don't provide source listings with >embedded error messages, is that this would require two standard >outputs, one for the listing and one for the task image. Years ago Marc Rochkind built something at Bell Labs known as the two dimensional shell (2dsh), which could accomodate nonlinear pipelines. I forget the details and I don't know whatever became of the idea. George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA