Is Programming Obsolete?
========================
Brian Harvey
University of California, Berkeley
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.
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.
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 do mathematics, rather
than merely learn about it.
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.
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.
These are the roots of the current conventional wisdom that
programming, as an activity for students, is obsolete.
But It's Not!
1. People want to program.
==========================
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 so desperate 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.
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.
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.
2. Learning isn't just curriculum.
==================================
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.
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.
3. Learner-centered computing.
==============================
Here are two examples, at different age levels, of using computer
programming to teach other subjects in a learner-centered way.
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.)
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
(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.)
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 group, a mathematical structure made up of a set S
and an operation o that satisfy certain requirements. Those
requirements are tested by the procedures:
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;
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.
GUIs Versus Programming?
========================
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.
The dichotomy is false. The best software combines 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."
Here are my criteria for good interface design: ===============================================
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.
2. Anything that can be done with a graphical control must also be
doable from within a program in the extension language.
3. The algorithm for each graphical control should be accessible and
modifiable using the extension language.
4. It should be possible for the user to install new graphical
controls, with functions specified in the extension language.
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.
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.
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.
From: <
http://people.eecs.berkeley.edu/~bh/obsolete.html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)