<HTML>
<HEAD>
<TITLE>Is Programming Obsolete?</TITLE>
</HEAD>
<BODY>
<H1>Is Programming Obsolete?</H1>
<CITE>Brian Harvey<BR>University of California, Berkeley</CITE>
<P>My topic, the role of programming in computer-using education, is the
intersection of two broader topics: the role of programming in computer use
generally, and the goals and objectives behind the use of computers in
education.
<P>The first personal computers came with a BASIC interpreter, and with little
or no other software. Of necessity, anyone who wanted to use a computer
programmed it. The question for educators was not "Should students program
the computer or use it in some other way," but rather, "Should we spend the
money on computers for the students to program?" When computers were
brought into schools, the typical result is that some kids were deeply
engaged in programming them, while others ignored them.
<P>Soon teachers and others began to develop computer programs intended to
teach specific lessons. These programs ranged from drill and practice to
simulations. The early programs were narrowly focused; each program taught
one lesson. This was the context in which Logo became famous when its
developers argued for preferring programming as a student activity over the
use of drill programs and the like, on the grounds that programming engages
the mind in mathematical activity; students who program in Logo would <EM>do</EM>
mathematics, rather than merely <EM>learn about</EM> it.
<P>Today the situation is very different. The Macintosh was the first personal
computer to be sold without a programming language at all; instead the first
Macs came with a word processor and a painting program. Software has become
a giant industry, with many choices available in all categories. People
expect to use computers without programming them; programming is seen as a
task for experts.
<P>Another factor in the changing view of programming is the increasing
complexity and sophistication of user interfaces. Commercial software has a
professional "look and feel" that the old homebrew BASIC programs can't
match. Kids expect arcade-quality animation and a graphical user interface.
The programs that they can write themselves don't meet that standard.
<P>These are the roots of the current conventional wisdom that programming, as
an activity for students, is obsolete.
<H2>But It's Not!</H2>
<H3>1. People want to program.</H3>
<P>If you ask most computer users, they'll tell you that they don't want to
program. The word "programming" has come to connote something horribly
complicated, beyond the ability of most people. But the people who say they
don't want to program are wrong. The proof is that they buy "macro"
languages, such as QuickKeys. These are abysmally poor programming
languages, in which the notation is based on keystrokes and mouse clicks
rather than on the desired program functions, and yet people put up with
their awfulness because they are <EM>so desperate</EM> to program their computers!
They don't express their desperation in those terms; they say that they
merely want the computer to carry out their tasks, which aren't exactly the
ones built into the commercial software. But teaching a computer to carry
out a desired task is precisely what "programming" really means.
<P>Macro languages are awkward because they are retrofitted into a system
designed to prevent programming. In recent years, the computer system
designers have begun to recognize users' passionate desire to program, and
have developed programming languages that are better integrated with their
overall systems. The first example was Hypertalk, the programming language
within the Hypercard application program. Unfortunately, Apple was so
terrified that their customers would be scared away by the phrase
"programming language" that they made two bad mistakes with Hypertalk. The
first, which I find very revealing, was that in the first release of
Hypercard the programming language was hidden. Users had to take the
trouble to declare themselves expert before they could even look at, let
alone write, Hypertalk programs. The second mistake was to think that the
way to make a language easy for beginners is to make it "English-like."
This is the same mistake that led to the design of COBOL a generation ago,
one more illustration of the old saw about repeating the mistakes of history.
<P>Still, Hypercard was a big success, precisely because it acknowledged the
desire of users to program their computers. In the world of education,
we've seen a new flowering of educational Hypercard programs written by
teachers and students, similar to the earlier explosions of educational
programming in BASIC and in Logo. And better languages have followed; Apple
has finally introduced Apple Events, which makes most Macintosh software
extensible, and Microsoft has introduced Visual BASIC to make the PC
programmable by its users. Word processing programs such as Microsoft Word
have added extension languages, and so have spreadsheet and database
programs. But many of these ad hoc languages, such as DBASE for database
programming, are badly designed and lack essential capabilities.
<H3>2. Learning isn't just curriculum.</H3>
<P>Everyone likes to quote the remark that "education is what's left after you
forget everything you learned," but we sometimes evaluate educational
computing plans as if that weren't true, as if what's important were the
specific facts. Schools spend fortunes on enormous catalogs of programs,
each of which imparts one lesson. But the best, most enduring examples of
educational software are the ones that allow students to create the lesson
themselves -- in other words, the ones in which the learner programs the
computer.
<P>This doesn't have to mean that the student works in a general-purpose
programming language. Some of the best educational software consists of
special-purpose languages, such as Geometric Supposer and its descendents
like Geometer's Sketchpad. The design of special-purpose programming
languages for educational use has a long history. One very early, well
known example is Rocky's Boots, a (visual!) programming language for
propositional logic. The IBM "Writing to Read" package, while not really a
programming language, follows a similar approach, in that the learner is
encouraged to create something -- in this case, an English text -- rather
than merely to take in knowledge and regurgitate it on demand. In all of
these cases, learning to program isn't the goal; the goal is to learn
geometry, or logic, or reading skills. But programming isn't a distraction!
It helps in the learning, and it helps make the learning endure for the
student.
<H3>3. Learner-centered computing.</H3>
<P>Here are two examples, at different age levels, of using computer
programming to teach other subjects in a learner-centered way.
<P>The first is an investigation into English grammar, suitable for upper
elementary grades. Instead of learning abstract definitions for the parts
of speech ("A noun is a person, place, or thing" and so on), students can
discover for themselves which words fit into what roles in a sentence, by
constructing a sentence-generation program in Logo. (This activity is
inspired by _Exploring Languge with Logo_ by E. Paul Goldenberg and
Wallace Feurzeig.)
<PRE>
to sent
output (sentence nounphrase verbphrase)
end
to nounphrase
output (sentence "the adjective noun)
end
to verbphrase
output (sentence verb nounphrase)
end
to noun
output pick [girl boy elephant zebra giraffe clown]
end
to adjective
output pick [big happy little funny silly]
end
to verb
output pick [hugs punches likes visits]
end
? print sent
THE FUNNY CLOWN HUGS THE HAPPY ZEBRA
? print sent
THE LITTLE GIRAFFE PUNCHES THE SILLY BOY
</PRE>
(This program would not be presented to students by the teacher. Rather,
the students would build up to it themselves. Perhaps the teacher would
present a much simpler program, for example, one that generates sentences
such as FRED RUNS or SUSAN SMILES. This is an open-ended project; the
program can be extended to generate many different sentence structures.)
<P>The second example is for college undergraduates learning abstract algebra.
These procedures are written in ISETL, a language designed specifically to
resemble formal mathematical notation. They come from an algebra course
taught by Uri Leron. The procedures model the definition of a <EM>group</EM>, a
mathematical structure made up of a set S and an operation o that satisfy
certain requirements. Those requirements are tested by the procedures:
<PRE>
is_closed := func(S,o);
return
forall a,b in S |
a .o b in S;
end;
is_associative := func(S,o);
return
forall a,b,c in S |
(a .o b) .o c = a .o (b .o c);
end;
has_identity := func(S,o);
return
exists e in S |
(forall a in S | e .o a = a);
end;
identity := func(S,o);
return
choose e in S |
(forall a in S | e .o a = a);
end;
has_inverses := func(S,o);
local e; e := identity(S,o);
return
is_defined(e) and
forall a in S |
(exists a' in S | a' .o a = e);
end;
</PRE>
<P>I choose this advanced example to make the point that the difficulties of a
ten-year-old learning the parts of speech is not so different from those of
a twenty-year-old studying mathematics. In both cases, the curriculum
consists of a series of technical terms (adjective in one case, associative
in the other) and their meanings. If a teacher recites defnitions for these
terms, the student can easily be confused or forget them later. But if each
learner develops the ideas through experimentation, they are more likely to
form a coherent framework. Programming languages are a vehicle for that
experimentation.
<H2>GUIs Versus Programming?</H2>
<P>In the popular culture, a distinction is made between computer systems for
programmers (DOS, Unix) and computer systems for non-programmers (Macintosh,
Windows). Fans of the latter category are the ones who most strongly
suggest that programming is obsolete as an activity for learners.
<P>The dichotomy is false. The best software <EM>combines</EM> a graphical user
interface with a powerful extension language. In the early days of Logo, the
slogan was "No threshold, no ceiling." In modern vocabulary, this same idea
is still relevant: "Simple things should be simple, and difficult things
should be possible."
<P>Here are my criteria for good interface design:
<P>1. Commonly-used capabilities of the program should be accessible through
graphical controls (by clicking on a button or moving a slider, for example)
without programming.
<P>2. Anything that can be done with a graphical control must also be doable
from within a program in the extension language.
<P>3. The algorithm for each graphical control should be accessible and
modifiable using the extension language.
<P>4. It should be possible for the user to install new graphical controls,
with functions specified in the extension language.
<P>5. The extension language should be a real, well designed programming
language, not an ad hoc kludge. It should provide the capabilities of
serious modern languages, such as dynamic memory allocation, functional
programming, and object-oriented programming.
<P>There are a few examples of such hybrid programs. AutoCAD, a program used
by circuit designers, has a graphical interface with Lisp as an extension
language. Michael Eisenberg has developed SchemePaint, a painting program
with a conventional graphical interface backed up with Scheme as the
extension language. For example, the SchemePaint user can define new
brushes to add to the program's tool palette. Microworlds, the latest
product from Logo Computer Systems, Inc., is an animated paint program with
user extensions programmable in Logo.
<P>As programs like these become more and more common, will the people who use
them think of themselves as programmers? No doubt some will and some won't,
but the ones who do will get the most benefit from their tools.
<P><ADDRESS>
<A HREF="index.html"><CODE>www.cs.berkeley.edu/~bh</CODE></A>
</ADDRESS>
</BODY>
</HTML>