Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!caesar.cs.montana.edu!ogccse!dinucci
From: dinucci@ogccse.ogc.edu (David C. DiNucci)
Newsgroups: comp.lang.visual,comp.lang.misc
Subject: Re: metaphor and programming
Message-ID: <5623@ogccse.ogc.edu>
Date: 15 Nov 89 01:47:02 GMT
References: <13770@orstcs.CS.ORST.EDU>
Reply-To: dinucci@ogccse.UUCP (David C. DiNucci)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 108

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