Rapid Prototyping in Interactive Programming Environments
This is a position statement written by
in September 1988 for Robin Schaufler's proposed CHI panel called
"Rapid Prototyping in Interactive Programming Environments".
The panel unfortunately never took place, but the statements still apply.
The comments about programming in
also apply to
and other languages.
Two general schools of thought exist on the subject of rapid prototyping.
One school of thought advocates the use of graphical tools; the other advocates
the use of interactive language environments. This panel focusses on the
latter school of thought. The panelists attempt to characterise the benefits
and drawbacks of interpretive language environments for rapid prototyping
in general, and examine the relative benefits and drawbacks of the specific
languages they represent.
Some pertinent questions to be addressed are:
- What productivity gains do interactive programming environments provide
over batch compilers?
- A good interactive programming environment puts the full power of
the extension language at your disposal, giving you immediate and direct
access to the functions and data structures that compose the system.
You can display and modify live data structures, and examine, call, and
redefine functions from the keyboard. You can implement, test, analyze,
and revise modules of code, without writing stand-alone drivers to test
out each module, and without recompiling and relinking after every change.
- Why use an interactive language rather than a graphical prototyping
- Graphical prototyping systems are generally very good at what they're
designed to do, but aren't applicable outside their narrow domain.
Interactive programming environments are more widely applicable, and they
can be extended to implement interfaces and communication protocols tailored
to the needs of specific applications.
NeWS window system
and the Emacs text
editor provide programmers with a high level of power and flexibility, to
rapidly prototype, evaluate, and implement unconventional ideas. Much of
the prototype code can be reused in the final system.
Emacs and NeWS are especially useful for creating front ends for command
line driven program. Operating system processes can be run under the control
of Emacs, which can provide them with pre-processed input, and capture and
manipulate their output. With NeWS, a programmer can use object oriented
PostScript to build a graphical front end to an application that provides
local input processing and feedback, resulting in low client/server network
traffic and high interactive performance.
- How expert must a user interface designer be in programming in general
to derive productivity gains from an interactive programming environment?
- The presence of an extension language in a rapid prototyping system
does not preclude that the system is usable by non-programmers. Programmers
can use the extension language to create a concise, application specific
command language that is easy for non-programmers to use.
Novice programmers can take advantage of pre-defined commands and objects,
putting them together and customizing building blocks written by other people.
Experienced programmers can take full advantage of the power and flexibility
of the extension language, creating their own building blocks, which others
- How expert must a user interface designer be in a specific interactive
language, to derive productivity gains from using that language?
- A language is easier to learn interactively that in a batch environment.
Direct access and immediate feedback gives a programmer immersed in an interpretive
environment intimate experience with the language, and incentive to experiment.
Using object oriented programming in NeWS, programmers can utilize pre-defined
classes of objects without knowing about their internals, and they can make
their own custom classes by subclassing already existing classes. NeWS supports
this building block approach very well.
Emacs, which runs on dumb terminals as well as window systems, provides
an integrated program development system, with online documentation, command
name completion, and many packages of specialized editing functions that
can be bound to key sequences, or used in building higher level packages.
- How does one migrate from prototype to product?
- How would you prioritize the importance to a user interface designer's
productivity among: use of an interactive environment, the particular language
chosen, and pre-existing library or component packages?
- Use of an interactive environment. You've got to be able to participate
in the environment.
- The particular language chosen. It's got to be an environment worth
- Pre-existing library or component packages. You need a solid base
on top of which to build, and some concrete examples of how things are put
- Once a user interface designer has elected to use an interactive language,
how does he select the language?