Design and Research

****

| January 2003(This article is derived from a keynote talk at the fall 2002 meeting
of NEPLS.)Visitors to this country are often surprised to find that
Americans like to begin a conversation by asking "what do you do?"
I've never liked this question. I've rarely had a
neat answer to it. But I think I have finally solved the problem.
Now, when someone asks me what I do, I look them straight
in the eye and say "I'm designing a
new dialect of Lisp."
I recommend this answer to anyone who doesn't like being asked what
they do. The conversation will turn immediately to other topics.I don't consider myself to be doing research on programming languages.
I'm just designing one, in the same way that someone might design
a building or a chair or a new typeface.
I'm not trying to discover anything new. I just want
to make a language that will be good to program in. In some ways,
this assumption makes life a lot easier.The difference between design and research seems to be a question
of new versus good. Design doesn't have to be new, but it has to
be good. Research doesn't have to be good, but it has to be new.
I think these two paths converge at the top: the best design
surpasses its predecessors by using new ideas, and the best research
solves problems that are not only new, but actually worth solving.
So ultimately we're aiming for the same destination, just approaching
it from different directions.What I'm going to talk about today is what your target looks like
from the back. What do you do differently when you treat
programming languages as a design problem instead of a research topic?The biggest difference is that you focus more on the user.
Design begins by asking, who is this
for and what do they need from it? A good architect,
for example, does not begin by creating a design that he then
imposes on the users, but by studying the intended users and figuring
out what they need.Notice I said "what they need," not "what they want." I don't mean
to give the impression that working as a designer means working as
a sort of short-order cook, making whatever the client tells you
to. This varies from field to field in the arts, but
I don't think there is any field in which the best work is done by
the people who just make exactly what the customers tell them to.The customer is always right in
the sense that the measure of good design is how well it works
for the user. If you make a novel that bores everyone, or a chair
that's horribly uncomfortable to sit in, then you've done a bad
job, period. It's no defense to say that the novel or the chair
is designed according to the most advanced theoretical principles.And yet, making what works for the user doesn't mean simply making
what the user tells you to. Users don't know what all the choices
are, and are often mistaken about what they really want.The answer to the paradox, I think, is that you have to design
for the user, but you have to design what the user needs, not simply
what he says he wants.
It's much like being a doctor. You can't just treat a patient's
symptoms. When a patient tells you his symptoms, you have to figure
out what's actually wrong with him, and treat that.This focus on the user is a kind of axiom from which most of the
practice of good design can be derived, and around which most design
issues center.If good design must do what the user needs, who is the user? When
I say that design must be for users, I don't mean to imply that good
design aims at some kind of
lowest common denominator. You can pick any group of users you
want. If you're designing a tool, for example, you can design it
for anyone from beginners to experts, and what's good design
for one group might be bad for another. The point
is, you have to pick some group of users. I don't think you can
even talk about good or bad design except with
reference to some intended user.You're most likely to get good design if the intended users include
the designer himself. When you design something
for a group that doesn't include you, it tends to be for people
you consider to be less sophisticated than you, not more sophisticated.That's a problem, because looking down on the user, however benevolently,
seems inevitably to corrupt the designer.
I suspect that very few housing
projects in the US were designed by architects who expected to live
in them. You can see the same thing
in programming languages. C, Lisp, and Smalltalk were created for
their own designers to use. Cobol, Ada, and Java, were created
for other people to use.If you think you're designing something for idiots, the odds are
that you're not designing something good, even for idiots.
Even if you're designing something for the most sophisticated
users, though, you're still designing for humans. It's different
in research. In math you
don't choose abstractions because they're
easy for humans to understand; you choose whichever make the
proof shorter. I think this is true for the sciences generally.
Scientific ideas are not meant to be ergonomic.Over in the arts, things are very different. Design is
all about people. The human body is a strange
thing, but when you're designing a chair,
that's what you're designing for, and there's no way around it.
All the arts have to pander to the interests and limitations
of humans. In painting, for example, all other things being
equal a painting with people in it will be more interesting than
one without. It is not merely an accident of history that
the great paintings of the Renaissance are all full of people.
If they hadn't been, painting as a medium wouldn't have the prestige
that it does.Like it or not, programming languages are also for people,
and I suspect the human brain is just as lumpy and idiosyncratic
as the human body. Some ideas are easy for people to grasp
and some aren't. For example, we seem to have a very limited
capacity for dealing with detail. It's this fact that makes
programing languages a good idea in the first place; if we
could handle the detail, we could just program in machine
language.Remember, too, that languages are not
primarily a form for finished programs, but something that
programs have to be developed in. Anyone in the arts could
tell you that you might want different mediums for the
two situations. Marble, for example, is a nice, durable
medium for finished ideas, but a hopelessly inflexible one
for developing new ideas.A program, like a proof,
is a pruned version of a tree that in the past has had
false starts branching off all over it. So the test of
a language is not simply how clean the finished program looks
in it, but how clean the path to the finished program was.
A design choice that gives you elegant finished programs
may not give you an elegant design process. For example,
I've written a few macro-defining macros full of nested
backquotes that look now like little gems, but writing them
took hours of the ugliest trial and error, and frankly, I'm still
not entirely sure they're correct.We often act as if the test of a language were how good
finished programs look in it.
It seems so convincing when you see the same program
written in two languages, and one version is much shorter.
When you approach the problem from the direction of the
arts, you're less likely to depend on this sort of
test. You don't want to end up with a programming
language like marble.For example, it is a huge win in developing software to
have an interactive toplevel, what in Lisp is called a
read-eval-print loop. And when you have one this has
real effects on the design of the language. It would not
work well for a language where you have to declare
variables before using them, for example. When you're
just typing expressions into the toplevel, you want to be
able to set x to some value and then start doing things
to x. You don't want to have to declare the type of x
first. You may dispute either of the premises, but if

[...]

Original source