The Hundred-Year Language

[The Hundred-Year Language]

****

****

| April 2003(This essay is derived from a keynote talk at PyCon 2003.)It's hard to predict what
life will be like in a hundred years. There are only a few
things we can say with certainty. We know that everyone will
drive flying cars,
that zoning laws will be relaxed to allow buildings
hundreds of stories tall, that it will be dark most of the
time, and that women will all be trained in the martial arts.
Here I want to zoom in on one detail of this
picture. What kind of programming language will they use to
write the software controlling those flying cars?This is worth thinking about not so
much because we'll actually get to use these languages as because,
if we're lucky, we'll use languages on the path from this
point to that.I think that, like species, languages will form evolutionary trees,
with dead-ends branching off all over. We can see this
happening already.
Cobol, for all its sometime popularity, does not seem to have any
intellectual descendants. It is an evolutionary dead-end-- a
Neanderthal language.I predict a similar fate for Java. People
sometimes send me mail saying, "How can you say that Java
won't turn out to be a successful language? It's already
a successful language." And I admit that it is, if you
measure success by shelf space taken up by books on it
(particularly individual books on it), or by
the number of undergrads who believe they have to
learn it to get a job. When I say Java won't
turn out to be a successful language, I mean something more
specific: that Java
will turn out to be an evolutionary dead-end, like Cobol.This is just a guess. I may be wrong. My point here is not to dis Java,
but to raise the issue of evolutionary
trees and get people asking, where on the tree is language X?
The reason to ask this question isn't just so that
our ghosts can say, in a
hundred years, I told you so. It's because staying close to
the main branches is a useful heuristic for finding languages that will
be good to program in now.At any given time, you're probably happiest on
the main branches of an evolutionary tree.
Even when there were still plenty of Neanderthals,
it must have sucked to be one. The
Cro-Magnons would have been constantly coming over and
beating you up and stealing your food.The reason I want to
know what languages will be like in a hundred years is so that
I know what branch of the tree to bet on now.The evolution of languages differs from the evolution of species
because branches can converge. The Fortran branch, for example,
seems to be merging with the descendants
of Algol. In theory this is possible for species too, but it's
not likely to have happened to any bigger than a cell.Convergence
is more likely for languages partly because the space of
possibilities is smaller, and partly because mutations
are not random. Language designers deliberately incorporate
ideas from other languages.It's especially useful for language designers to think
about where the evolution of programming languages is likely
to lead, because they can steer accordingly.
In that case, "stay on a main branch" becomes more than a
way to choose a good language.
It becomes a heuristic for making the right decisions about
language design.Any programming language can be divided into
two parts: some set of fundamental operators that play the role
of axioms, and the rest of the language, which could in principle
be written in terms of these fundamental operators.I think the fundamental operators are the most important factor in a
language's long term survival. The rest you can change. It's
like the rule that in buying a house you should consider
location first of all. Everything else you can fix later, but you
can't fix the location.I think it's important not just that the axioms be well chosen,
but that there be few of them. Mathematicians have always felt
this way about axioms-- the fewer, the better-- and I think they're
onto something.At the very least, it has to be a useful exercise to look closely
at the core of a language to see if there are any axioms that
could be weeded out. I've found in my long career as a slob that
cruft breeds cruft, and I've seen this happen in software as
well as under beds and in the corners of rooms.I have a hunch that
the main branches of the evolutionary tree pass through the languages
that have the smallest, cleanest cores.
The more of a language you can write in itself,
the better.Of course, I'm making a big assumption in even asking what
programming languages will be like in a hundred years.
Will we even be writing programs in a hundred years? Won't
we just tell computers what we want them to do?There hasn't been a lot of progress in that department
so far.
My guess is that a hundred years from now people will
still tell computers what to do using programs we would recognize
as such. There may be tasks that we
solve now by writing programs and which in a hundred years
you won't have to write programs to solve, but I think
there will still be a good deal of
programming of the type that we do today.It may seem presumptuous to think anyone can predict what
any technology will look like in a hundred years. But
remember that we already have almost fifty years of history behind us.
Looking forward a hundred years is a graspable idea
when we consider how slowly languages have evolved in the
past fifty.Languages evolve slowly because they're not really technologies.
Languages are notation. A program is a formal description of
the problem you want a computer to solve for you. So the rate
of evolution in programming languages is more like the
rate of evolution in mathematical notation than, say,
transportation or communications.
Mathematical notation does evolve, but not with the giant
leaps you see in technology.Whatever computers are made of in a hundred years, it seems
safe to predict they will be much faster than
they are now. If Moore's Law continues to put out, they will be 74
quintillion (73,786,976,294,838,206,464) times faster. That's kind of
hard to imagine. And indeed, the most likely prediction in the
speed department may be that Moore's Law will stop working.
Anything that is supposed to double every eighteen months seems
likely to run up against some kind of fundamental limit eventually.
But I have no trouble believing that computers will be very much
faster. Even if they only end up being a paltry million
times faster, that should change the ground rules for programming
languages substantially. Among other things, there
will be more room for what
would now be considered slow languages, meaning languages
that don't yield very efficient code.And yet some applications will still demand speed.
Some of the problems we want to solve with
computers are created by computers; for example, the
rate at which you have to process video images depends
on the rate at which another computer can
generate them. And there is another class of problems
which inherently have an unlimited capacity to soak up cycles:
image rendering, cryptography, simulations.If some applications can be increasingly inefficient while
others continue to demand all the speed the hardware can
deliver, faster computers will mean that languages have
to cover an ever wider range of efficiencies. We've seen
this happening already. Current implementations of some
popular new languages are shockingly wasteful by the
standards of previous decades.This isn't just something that happens with programming
languages. It's a general historical trend. As technologies improve,
each generation can do things that the previous generation
would have considered wasteful. People thirty years ago would
be astonished at how casually we make long distance phone calls.
People a hundred years ago would be even more astonished that
a package would one day travel from Boston to New York via Memphis.I can already tell you what's going to happen to all those extra

[...]

Original source