rss-bridge 2026-03-01T21:54:49.418468407+00:00

Five Questions about Language Design

[Five Questions about Language Design]

****

| May 2001

(These are some notes I made
for a panel discussion on programming language design
at MIT on May 10, 2001.)1. Programming Languages Are for People.Programming languages
are how people talk to computers. The computer would be just as
happy speaking any language that was unambiguous. The reason we
have high level languages is because people can't deal with
machine language. The point of programming
languages is to prevent our poor frail human brains from being
overwhelmed by a mass of detail.Architects know that some kinds of design problems are more personal
than others. One of the cleanest, most abstract design problems
is designing bridges. There your job is largely a matter of spanning
a given distance with the least material. The other end of the
spectrum is designing chairs. Chair designers have to spend their
time thinking about human butts.Software varies in the same way. Designing algorithms for routing
data through a network is a nice, abstract problem, like designing
bridges. Whereas designing programming languages is like designing
chairs: it's all about dealing with human weaknesses.Most of us hate to acknowledge this. Designing systems of great
mathematical elegance sounds a lot more appealing to most of us
than pandering to human weaknesses. And there is a role for mathematical
elegance: some kinds of elegance make programs easier to understand.
But elegance is not an end in itself.And when I say languages have to be designed to suit human weaknesses,
I don't mean that languages have to be designed for bad programmers.
In fact I think you ought to design for the
best programmers, but
even the best programmers have limitations. I don't think anyone
would like programming in a language where all the variables were
the letter x with integer subscripts.2. Design for Yourself and Your Friends.If you look at the history of programming languages, a lot of the best
ones were languages designed for their own authors to use, and a
lot of the worst ones were designed for other people to use.When languages are designed for other people, it's always a specific
group of other people: people not as smart as the language designer.
So you get a language that talks down to you. Cobol is the most
extreme case, but a lot of languages are pervaded by this spirit.It has nothing to do with how abstract the language is. C is pretty
low-level, but it was designed for its authors to use, and that's
why hackers like it.The argument for designing languages for bad programmers is that
there are more bad programmers than good programmers. That may be
so. But those few good programmers write a disproportionately
large percentage of the software.I'm interested in the question, how do you design a language that
the very best hackers will like? I happen to think this is
identical to the question, how do you design a good programming
language?, but even if it isn't, it is at least an interesting
question.3. Give the Programmer as Much Control as Possible.Many languages
(especially the ones designed for other people) have the attitude
of a governess: they try to prevent you from
doing things that they think aren't good for you. I like the
opposite approach: give the programmer as much
control as you can.When I first learned Lisp, what I liked most about it was
that it considered me an equal partner. In the other languages
I had learned up till then, there was the language and there was my
program, written in the language, and the two were very separate.
But in Lisp the functions and macros I wrote were just like those
that made up the language itself. I could rewrite the language
if I wanted. It had the same appeal as open-source software.4. Aim for Brevity.Brevity is underestimated and even scorned.
But if you look into the hearts of hackers, you'll see that they
really love it. How many times have you heard hackers speak fondly
of how in, say, APL, they could do amazing things with just a couple
lines of code? I think anything that really smart people really
love is worth paying attention to.I think almost anything
you can do to make programs shorter is good. There should be lots
of library functions; anything that can be implicit should be;
the syntax should be terse to a fault; even the names of things
should be short.And it's not only programs that should be short. The manual should
be thin as well. A good part of manuals is taken up with clarifications
and reservations and warnings and special cases. If you force
yourself to shorten the manual, in the best case you do it by fixing
the things in the language that required so much explanation.5. Admit What Hacking Is.A lot of people wish that hacking was
mathematics, or at least something like a natural science. I think
hacking is more like architecture. Architecture is
related to physics, in the sense that architects have to design
buildings that don't fall down, but the actual goal of architects
is to make great buildings, not to make discoveries about statics.What hackers like to do is make great programs.
And I think, at least in our own minds, we have to remember that it's
an admirable thing to write great programs, even when this work
doesn't translate easily into the conventional intellectual
currency of research papers. Intellectually, it is just as
worthwhile to design a language programmers will love as it is to design a
horrible one that embodies some idea you can publish a paper
about.1. How to Organize Big Libraries?Libraries are becoming an
increasingly important component of programming languages. They're
also getting bigger, and this can be dangerous. If it takes longer
to find the library function that will do what you want than it
would take to write it yourself, then all that code is doing nothing
but make your manual thick. (The Symbolics manuals were a case in
point.) So I think we will have to work on ways to organize
libraries. The ideal would be to design them so that the programmer
could guess what library call would do the right thing.2. Are People Really Scared of Prefix Syntax?This is an open
problem in the sense that I have wondered about it for years and
still don't know the answer. Prefix syntax seems perfectly natural
to me, except possibly for math. But it could be that a lot of
Lisp's unpopularity is simply due to having an unfamiliar syntax.
Whether to do anything about it, if it is true, is another question.

3. What Do You Need for Server-Based Software?

I think a lot of the most exciting new applications that get written
in the next twenty years will be Web-based applications, meaning
programs that sit on the server and talk to you through a Web
browser. And to write these kinds of programs we may need some
new things.One thing we'll need is support for the new way that server-based
apps get released. Instead of having one or two big releases a
year, like desktop software, server-based apps get released as a
series of small changes. You may have as many as five or ten
releases a day. And as a rule everyone will always use the latest
version.You know how you can design programs to be debuggable?
Well, server-based software likewise has to be designed to be
changeable. You have to be able to change it easily, or at least
to know what is a small change and what is a momentous one.Another thing that might turn out to be useful for server based
software, surprisingly, is continuations. In Web-based software
you can use something like continuation-passing style to get the
effect of subroutines in the inherently
stateless world of a Web
session. Maybe it would be worthwhile having actual continuations,
if it was not too expensive.4. What New Abstractions Are Left to Discover?I'm not sure how
reasonable a hope this is, but one thing I would really love to

[...]

Original source