🚀 go-pugleaf

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

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

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  97006

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)

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		|

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

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

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

[ 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)

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

> dave@fps.com (Dave Smith)
> Unix pipe programs are one dimensional because they're limited by the shells
> to be one dimensional.   [...]
> I'd prefer to [..do something like..]:
>				    /-awk 'control string 1' > x1
>	producer_prog | sed | grep <
>				    \-awk 'control string 2' > x2

This particular trick can actually be done with the bourne shell as it
currently exists.  Of course, just arbitrarily drawing two dataflows out
of the grep doesn't make the program capable of producing two
datastreams.  We would have to get used to more "pipe fitting" programs
or switches to existing programs.  I'll ignore that, and produce just
the example above:

   producer_prog|sed|(grep|awk 's1' >x1&) 3>&1 | awk 's2' >x2

(This is, of course, asuming that "grep" produces one datastream
 on descriptor 1, and another on descriptor 3.)

> The other thing that would be quite nice would be to have more than one
> input to a program be a pipe [..like..]
>	pipe1 -\
>		> diff
>	pipe2 -/

This, too, is possible in the bourne shell off-the-shelf.  Again, it is
necessary to suppose that diff can take two input streams, and so this
would require a variant of diff, or an additional switch to diff.  But
be that as it may:

      pipe1 | (pipe2 | diff) 3<&0

(This is assuming that "diff" will take an additional input on f.d. 3.)

> 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...

Well, ugly as the bourne shell syntax for these things is, and limited
as it is (it can't for example produce two dataflows between just two
processes, nor a circular dataflow, nor many others), it IS ALREADY a
start.  Why not start using it, and expand on it by writing pipe
fittings as needed, like the "split" option of grep, or the "join"
option of diff, and others? Then, when a fancy graphical user interface
with allows for multiple data flows into and out of programs occurs, the
primitives necessary to using it will already exist. 

(Another very interesting "pipe fitting" program is one that will
 produce named pipes in the file system.  That way, programs which
 require filenames (such as diff) can be put into a pipe.  The above
 examples might be done like so with two primitives:
         ... |psplit "grep e1|awk 's1' >x1" "grep e2|awk 's2' >x2"
         pjoin f1 "pipe1" f2 "pipe2" "diff $f1 $f2" | ...
 Once you've written psplit and pjoin, you can do a lot, fairly nicely.
 Further, a graphical dataflow program could be trained to use them to
 produce the various fittings in the dataflow, while using existing
 unix tools as the nodes. )

In any event, if one really wants to exploit complicated pipe dataflows,
the thing to do is just go ahead and do it something like the way outlined
above.  Waiting for neat graphical-oriented dataflow shells to become
widely available just hasn't worked for me in the past... this has.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org

In article <0207@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
 >
 >Well, ugly as the bourne shell syntax for these things is, and limited
 >as it is (it can't for example produce two dataflows between just two
 >processes, nor a circular dataflow, nor many others), it IS ALREADY a
 >start.  Why not start using it, and expand on it by writing pipe
 >fittings as needed, like the "split" option of grep, or the "join"
 >option of diff, and others? 

Because writing the spiffy graphical interface is a whole lot more fun
than writing dataflow Bourne shell scripts.  :-)

--
David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"I'm trying to think, but nothing happens!" - Curly Fine

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) 

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) 

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.

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