No-code History: Pygmalion (1975)
Note: Almost all text below are quotes from resources listed at the end with slight editions.
Pygmalion being used to define factorial
Introduction
Pygmalion was an early attempt to improve the process of programming.
By studying how people think and communicate, it attempted to build a programming environment that facilitated communication and stimulated people's ability to think creatively.
While it never went beyond a toy system, Pygmalion embodied some ideas that still seem to have promise today:
It allowed ideas to be worked out via sketches on the screen and then was able to reexecute the sketches on new data.
It introduced icons as the basic entity for representing and controlling programs.
Programming was done by editing sketches and then recording the editing actions. This avoided the abstract step of writing down statements in a programming language.
Example data were always concrete, never abstract.
It used analogical representations for data. This reduced the translation distance between mental models and computer models of data.
It represented programs as movies.
Motivation
Its design was based on the observation that for some people blackboards provide significant aid to communication.
If you put two scientists together in a room, there had better be a blackboard in it or they will have trouble communicating.
If there is one, they will immediately go to it and begin sketching ideas. Their sketches often contribute as much to the conversation as their words and gestures. Why can't people communicate with computers in the same way?
Pygmalion was an attempt to allow people to use their enactive and iconic mentalities along with the symbolic in solving problems.
The Language
Pygmalion is a two-dimensional, visual programming environment.
It is both a programming language and a medium for experimenting with ideas. Communication between human and computer is by means of visual entities called "icons," subsuming the notions of variable, data structure, function and picture. Icons are sketched on the display screen.
The heart of the system is an interactive "remembering" editor for icons, which both executes operations and records them for later reexecution. The display screen is viewed as a picture to be edited.
Programming consists of creating a sequence of display images, the last of which contains the desired information.
In the Pygmalion approach, a programmer sees and thinks about a program as a series of screen images or snapshots, like the frames of a movie.
One starts with an image representing the initial state and transforms each image into the next by editing it to produce a new image. The programmer continues to edit until the desired picture appears. When one watches a program execute, it is similar to watching a movie. The difference is that, depending on the inputs, Pygmalion movies may change every time they are played.
How it Works
Below is a video demonstration:
The user creates programs by editing graphical snapshots of the computation. Essentially the user treats the display screen as an "electronic blackboard", using it to work out algorithms on specific concrete examples
Partially specified programs could be executed. The system asks the user what to do next when it reaches the end of a branch.
A person would define factorial by picking some number, say "6", and then working out the answer for factorial(6) using the display screen as a "blackboard."
The user invokes the "define" operation, and types in the name "factorial."
The first thing the system does with a newly created function is to capture the screen state.
Whenever the function is invoked, it restores the screen to this state. This is so that the function will execute the same way regardless of what is on the screen when it is called.
Icons may be deliberately left on the screen when a function is defined; these act as global variables. When the function is invoked, the "global" icons and their current values are restored to the screen and are therefore available to the function.
Whenever all the arguments to a function are filled in, the system immediately invokes it.
Functions in Pygmalion can be invoked even if their code is undefined or incomplete. When the system reaches a part of the function that has not yet been defined, it traps to the user asking what to do next.
The process will repeat until all parts are specified and the program can run to completion.
Finally, it restores the screen to its state when the function was initially invoked.
Retrospective
There are three main things the author would do differently:
Address a broader class of users. Pygmalion was designed for a specific target audience: computer scientists. These people already know how to program, and they understand programming concepts such as variables and iteration. Would like to see if the approach could be applied to a wider audience: business people, homemakers, teachers, children, the average "man on the street." This requires using objects and actions in the conceptual space of these users.
The biggest weakness of Pygmalion, and of all the programming by demonstration systems that have followed it to date, is that it is a toy system. Only simple algorithms could be programmed. The biggest challenge for programming by demonstration efforts is to build a practical system in which nontrivial programs can be written.
Put a greater emphasis on the user interface. Given what we know about graphical user interfaces today, it wouldn't be hard to improve the interface dramatically. Good esthetics are an important factor in the users' enjoyment of a system, and enjoyment is crucial to creativity.
Theory
Writing static language statements interspersed with compile-run-debug-edit periods is obviously a poor way to communicate. Suppose two humans tried to interact this way! Specifically, it is poor because it is:
- Abstract
-
The programmer must mentally construct a model of the state of the machine when the program will execute, and then write statements dealing with that imagined state.
We must find a way to allow programmers to work with concrete values without sacrificing generality.
- Non-interactive
-
Instead of speeding up the debug-edit-recompile loop, programmers should eliminate it!
- "Fregean"
-
The most articulate representation for a program requires the least translation between the internal representation in the mind and the external representation in the medium.
Aaron Sloman distinguishes two kinds of data representations: "analogical" and "Fregean".
Analogical representations are similar in structure to the things they describe
Fregean representations have no such similarity.
One of the advantages of analogical representations over Fregean ones is that structures and actions in a context using analogical representations (a "metaphorical" context) have a functional similarity to structures and actions in the context being modeled.
Jerome Bruner, in his pioneering work on education, identified three ways of thinking, or "mentalities":
- Enactive
-
in which learning is accomplished by doing. A baby learns what a rattle is by shaking it. A child learns to ride a bicycle by riding one.
- Iconic
-
in which learning and thinking utilize pictures. A child learns what a horse is by seeing one or a picture of one.
- Symbolic
-
in which learning and thinking are by means of Fregean symbols. One of the main goals of education today is to teach people to think symbolically.
All three mentalities are valuable at different times and can often be combined to solve problems. All three skills should be preserved.
Trivia
Pygmalion is the origin of the concept of icons as it now appears in graphical user interfaces on personal computers.
After completing his thesis, David Canfield Smith joined Xerox's "Star" computer project. The first thing he did was recast the programmer-oriented icons of Pygmalion into office-oriented ones representing documents, folders, file cabinets, mail boxes, telephones, wastebaskets, etc.
Pygmalion was implemented in Smalltalk on a computer wht 64 Kilobytes of RAM and no virtual memory.