🚀 go-pugleaf

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)