Is Programming Obsolete?

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

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.