The Hundred-Year Language

April 2003

Апрель 2003

(This essay is derived from a keynote talk at PyCon 2003.)

(Это эссе основано на кейноут-докладе на 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.

Я думаю, что языки, подобно видам, образуют эволюционные деревья, и от ствола повсюду отходят тупиковые ветви. Это уже происходит у нас на глазах. Cobol при всей его былой популярности, похоже, не оставил интеллектуальных потомков. Это эволюционный тупик — язык-неандерталец.

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.

Я предсказываю такую же судьбу Java. Мне иногда пишут: «Как вы можете говорить, что Java не окажется успешным языком? Он уже успешный язык». И я согласен, что это так, если мерить успех площадью полок, занятых книгами о нём (особенно отдельными книгами), или числом студентов, считающих, что должны его выучить ради работы. Когда я говорю, что Java не окажется успешным языком, я имею в виду нечто более конкретное: что Java окажется эволюционным тупиком, как 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.

Это просто догадка. Я могу ошибаться. Моя цель здесь не в том, чтобы поругать Java, а в том, чтобы поднять вопрос об эволюционных деревьях и заставить людей спрашивать: где на дереве язык X? Спрашивать это надо не для того, чтобы наши призраки через сто лет могли сказать «я же говорил». А потому, что держаться поближе к основным ветвям — полезная эвристика для поиска языков, на которых хорошо программировать прямо сейчас.

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.

Эволюция языков отличается от эволюции видов тем, что ветви могут сходиться. Ветвь Fortran, например, похоже, сливается с потомками Algol. Теоретически это возможно и для видов, но вряд ли это происходило с чем-то крупнее клетки.

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.

Из чего бы ни были сделаны компьютеры через сто лет, безопасно предсказать, что они будут гораздо быстрее, чем сейчас. Если закон Мура продолжит выдавать своё, они будут в 74 квинтиллиона (73 786 976 294 838 206 464) раз быстрее. Это сложно представить. И, по правде говоря, самым вероятным предсказанием по части скорости может быть то, что закон Мура перестанет работать. Что-либо, что должно удваиваться каждые восемнадцать месяцев, вероятно, рано или поздно упрётся в какой-то фундаментальный предел. Но мне нетрудно поверить, что компьютеры будут намного быстрее. Даже если они окажутся всего в жалкий миллион раз быстрее, это должно существенно изменить правила игры для языков программирования. Среди прочего, появится больше места для того, что сейчас считалось бы медленными языками, то есть языками, не дающими очень эффективного кода.

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
cycles that faster hardware is going to give us in the
next hundred years. They're nearly all going to be wasted.

Я уже сейчас могу сказать вам, что произойдёт со всеми лишними тактами, которые более быстрое железо даст нам в ближайшие сто лет. Почти все они будут потрачены впустую.

I learned to program when computer power was scarce.
I can remember taking all the spaces out of my Basic programs
so they would fit into the memory of a 4K TRS-80. The
thought of all this stupendously inefficient software
burning up cycles doing the same thing over and over seems
kind of gross to me. But I think my intuitions here are wrong. I'm
like someone who grew up poor, and can't bear to spend money
even for something important, like going to the doctor.

Я учился программировать, когда вычислительная мощность была в дефиците. Я помню, как убирал все пробелы из своих программ на Basic, чтобы они влезли в память 4К TRS-80. Мысль обо всём этом потрясающе неэффективном софте, который сжигает такты, делая одно и то же снова и снова, кажется мне какой-то противной. Но я думаю, что моя интуиция здесь ошибается. Я как человек, выросший в бедности и не способный заставить себя потратить деньги даже на что-то важное, например, поход к врачу.

Some kinds of waste really are disgusting. SUVs, for example, would
arguably be gross even if they ran on a fuel which would never
run out and generated no pollution. SUVs are gross because they're
the solution to a gross problem. (How to make minivans look more
masculine.)
But not all waste is bad. Now that we have the infrastructure
to support it, counting the minutes of your long-distance
calls starts to seem niggling. If you have the
resources, it's more elegant to think of all phone calls as
one kind of thing, no matter where the other person is.

Какие-то виды расточительства действительно отвратительны. Внедорожники, к примеру, по сути были бы мерзкими, даже если бы ездили на топливе, которое никогда не кончается и не даёт загрязнения. Внедорожники мерзки потому, что они — решение мерзкой задачи. (Как сделать минивэны более мужественными на вид.) Но не всякое расточительство плохо. Теперь, когда у нас есть инфраструктура, чтобы его себе позволить, считать минуты междугородних разговоров начинает казаться мелочностью. Если есть ресурсы, элегантнее воспринимать все телефонные звонки как одну сущность, где бы ни находился собеседник.

There's good waste, and bad waste. I'm interested
in good waste-- the kind where, by spending more, we can get
simpler designs. How will we take advantage of the opportunities
to waste cycles that we'll get from new, faster hardware?

Бывает хорошее расточительство, бывает плохое. Меня интересует хорошее — такое, при котором, тратя больше, мы получаем более простые решения. Как мы воспользуемся возможностями впустую тратить такты, которые даст нам новое, более быстрое железо?

The desire for speed is so deeply engrained in us, with
our puny computers, that it will take a conscious effort
to overcome it. In language design, we should be consciously seeking out
situations where we can trade efficiency for even the
smallest increase in convenience.

Стремление к скорости настолько глубоко в нас укоренено вместе с нашими хилыми компьютерами, что преодолеть его потребует сознательного усилия. В дизайне языков мы должны сознательно искать ситуации, где можно обменять эффективность даже на малейшее увеличение удобства.

Most data structures exist because of speed. For example,
many languages today have both strings and lists. Semantically, strings
are more or less a subset of lists in which the elements are
characters. So why do you need a separate data type?
You don't, really. Strings only
exist for efficiency. But it's lame to clutter up the semantics
of the language with hacks to make programs run faster.
Having strings in a language seems to be a case of
premature optimization.

Большинство структур данных существуют ради скорости. Например, во многих современных языках есть и строки, и списки. С точки зрения семантики строки — это более или менее подмножество списков, в которых элементы являются символами. Так зачем нужен отдельный тип данных? На самом деле не нужен. Строки существуют только ради эффективности. Но захламлять семантику языка хаками, заставляющими программы работать быстрее, — это убожество. Наличие строк в языке выглядит как случай преждевременной оптимизации.

If we think of the core of a language as a set of axioms,
surely it's gross to have additional axioms that add no expressive
power, simply for the sake of efficiency. Efficiency is
important, but I don't think that's the right way to get it.

Если мы воспринимаем ядро языка как набор аксиом, то добавлять лишние аксиомы, не добавляющие выразительной силы, исключительно ради эффективности — наверняка убогая идея. Эффективность важна, но я не думаю, что это правильный путь её получить.

The right way to solve that problem, I think, is to separate
the meaning of a program from the implementation details.
Instead of having both lists and strings, have just lists,
with some way to give the compiler optimization advice that
will allow it to lay out strings as contiguous bytes if
necessary.

Правильный способ решить эту проблему, думаю, — отделить смысл программы от деталей реализации. Вместо того чтобы иметь и списки, и строки, иметь только списки, с каким-то способом давать компилятору подсказки для оптимизации, которые позволят ему при необходимости расположить строки как непрерывные байты.

Since speed doesn't matter in most of a program, you won't
ordinarily need to bother with
this sort of micromanagement.
This will be more and more true as computers get faster.

Поскольку в большей части программы скорость не важна, обычно вам не придётся возиться с таким микроменеджментом. Это будет всё более верно по мере роста скорости компьютеров.

Saying less about implementation should also make programs
more flexible.
Specifications change while a program is being written, and this is not
only inevitable, but desirable.

Говорить меньше о реализации также должно делать программы более гибкими. Спецификации меняются по ходу написания программы, и это не только неизбежно, но и желательно.

The word "essay" comes
from the French verb "essayer", which means "to try".
An essay, in the original sense, is something you
write to try to figure something out. This happens in
software too. I think some of the best programs were essays,
in the sense that the authors didn't know when they started
exactly what they were trying to write.

Слово «essay» происходит от французского глагола «essayer», что значит «пробовать». Эссе в исходном смысле — это то, что вы пишете, пытаясь в чём-то разобраться. Это бывает и в софте. Я думаю, некоторые из лучших программ были эссе в том смысле, что авторы, начиная их, точно не знали, что именно они пытаются написать.

Lisp hackers already know about the value of being flexible
with data structures. We tend to write the first version of
a program so that it does everything with lists. These
initial versions can be so shockingly inefficient that it
takes a conscious effort not to think about what they're
doing, just as, for me at least, eating a steak requires a
conscious effort not to think where it came from.

Хакеры Lisp уже знают о ценности гибкости в выборе структур данных. Мы склонны писать первую версию программы так, чтобы всё делалось на списках. Эти начальные версии могут быть настолько шокирующе неэффективными, что требуется сознательное усилие не думать о том, что они делают, — так же, как, по крайней мере для меня, поедание стейка требует сознательного усилия не думать о том, откуда он взялся.

What programmers in a hundred years will be looking for, most of
all, is a language where you can throw together an unbelievably
inefficient version 1 of a program with the least possible
effort. At least, that's how we'd describe it in present-day
terms. What they'll say is that they want a language that's
easy to program in.

Чего программисты через сто лет будут искать больше всего — это язык, на котором можно с минимально возможными усилиями набросать неправдоподобно неэффективную версию 1 программы. По крайней мере, так бы мы это описали в сегодняшних терминах. Сами они скажут, что хотят язык, на котором легко программировать.

Inefficient software isn't gross. What's gross is a language
that makes programmers do needless work. Wasting programmer time
is the true inefficiency, not wasting machine time. This will
become ever more clear as computers get faster.

Неэффективный софт — это не убожество. Убожество — это язык, заставляющий программистов делать ненужную работу. Тратить впустую время программиста — вот настоящая неэффективность, а не машинное время. Это будет становиться всё яснее по мере того, как компьютеры будут становиться быстрее.

I think getting rid of strings is already something we
could bear to think about. We did it in Arc, and it seems
to be a win; some operations that would be awkward to
describe as regular expressions can be described
easily as recursive functions.

Я думаю, отказ от строк — это уже то, о чём мы могли бы себе позволить задуматься. Мы сделали это в Arc, и, похоже, это выигрыш; некоторые операции, которые было бы неудобно описывать как регулярные выражения, легко описываются как рекурсивные функции.

How far will this flattening of data structures go? I can think
of possibilities that shock even me, with my conscientiously broadened
mind. Will we get rid of arrays, for example? After all, they're
just a subset of hash tables where the keys are vectors of
integers. Will we replace hash tables themselves with lists?

Как далеко зайдёт это уплощение структур данных? Я могу представить варианты, которые шокируют даже меня с моим сознательно расширенным сознанием. Откажемся ли мы, к примеру, от массивов? В конце концов, это всего лишь подмножество хеш-таблиц, в которых ключи — это векторы целых чисел. Заменим ли мы сами хеш-таблицы списками?

There are more shocking prospects even than that. The Lisp
that McCarthy described in 1960, for example, didn't
have numbers. Logically, you don't need to have a separate notion
of numbers, because you can represent them as lists: the integer
n could be represented as a list of n elements. You can do math this
way. It's just unbearably inefficient.

Есть перспективы и пошокирующее. В Lisp, который McCarthy описал в 1960 году, например, не было чисел. Логически отдельное понятие чисел иметь не нужно, потому что их можно представлять как списки: целое число n можно представить как список из n элементов. Так можно заниматься математикой. Просто это невыносимо неэффективно.

No one actually proposed implementing numbers as lists in
practice. In fact, McCarthy's 1960 paper was not, at the time,
intended to be implemented at all. It was a theoretical exercise,
an attempt to create a more elegant alternative to the Turing
Machine. When someone did, unexpectedly, take this paper and
translate it into a working Lisp interpreter, numbers certainly
weren't represented as lists; they were represented in binary,
as in every other language.

На практике никто и не предлагал реализовывать числа как списки. На самом деле статья McCarthy 1960 года в то время вообще не предназначалась для реализации. Это было теоретическое упражнение, попытка создать более элегантную альтернативу машине Тьюринга. Когда же кто-то неожиданно взял эту статью и перевёл её в работающий интерпретатор Lisp, числа, конечно, представлялись не списками; они представлялись в двоичном виде, как и в любом другом языке.

Could a programming language go so far as to get rid of numbers
as a fundamental data type? I ask this not so much as a serious
question as as a way to play chicken with the future. It's like
the hypothetical case of an irresistible force meeting an
immovable object-- here, an unimaginably inefficient
implementation meeting unimaginably great resources.
I don't see why not. The future is pretty long. If there's
something we can do to decrease the number of axioms in the core
language, that would seem to be the side to bet on as t approaches
infinity. If the idea still seems unbearable in a hundred years,
maybe it won't in a thousand.

Может ли язык программирования зайти настолько далеко, чтобы избавиться от чисел как фундаментального типа данных? Я задаю этот вопрос не столько всерьёз, сколько как способ сыграть в «слабо» с будущим. Это как гипотетический случай встречи неудержимой силы с неподвижным объектом — здесь это встреча невообразимо неэффективной реализации с невообразимо большими ресурсами. Не вижу, почему нет. Будущее довольно длинное. Если есть что-то, что мы можем сделать, чтобы уменьшить число аксиом в ядре языка, то на эту сторону, похоже, и стоит ставить при t, стремящемся к бесконечности. Если идея всё ещё кажется невыносимой через сто лет, возможно, она перестанет казаться такой через тысячу.

Just to be clear about this, I'm not proposing that all numerical
calculations would actually be carried out using lists. I'm proposing
that the core language, prior to any additional notations about
implementation, be defined this way. In practice any program
that wanted to do any amount of math would probably represent
numbers in binary, but this would be an optimization, not part of
the core language semantics.

Чтобы было понятно: я не предлагаю, чтобы все численные вычисления действительно выполнялись с помощью списков. Я предлагаю, чтобы ядро языка, до каких-либо дополнительных нотаций о реализации, было определено именно так. На практике любая программа, которой надо хоть сколько-то заниматься математикой, скорее всего, представляла бы числа в двоичном виде, но это была бы оптимизация, а не часть семантики ядра языка.

Another way to burn up cycles is to have many layers of
software between the application and the hardware. This too is
a trend we see happening already: many recent languages are
compiled into byte code. Bill Woods once told me that,
as a rule of thumb, each layer of interpretation costs a
factor of 10 in speed. This extra cost buys you flexibility.

Ещё один способ сжигать такты — иметь множество слоёв ПО между приложением и железом. Это тоже тенденция, которую мы уже наблюдаем: многие современные языки компилируются в байт-код. Bill Woods однажды сказал мне, что, как правило большого пальца, каждый слой интерпретации обходится в коэффициент 10 по скорости. Эта дополнительная плата покупает вам гибкость.

The very first version of Arc was an extreme case of this sort
of multi-level slowness, with corresponding benefits. It
was a classic "metacircular" interpreter written
on top of Common Lisp, with a definite family resemblance
to the eval function defined in McCarthy's original Lisp paper.
The whole thing was only a couple hundred lines of
code, so it was very easy to understand and change. The
Common Lisp we used, CLisp, itself runs on top
of a byte code interpreter. So here we had two levels of
interpretation, one of them (the top one) shockingly inefficient,
and the language was usable. Barely usable, I admit, but
usable.

Самая первая версия Arc была крайним случаем такой многослойной медлительности — с соответствующими преимуществами. Это был классический «метациркулярный» интерпретатор, написанный поверх Common Lisp, с явным семейным сходством с функцией eval, определённой в оригинальной статье McCarthy о Lisp. Вся штука была всего парой сотен строк кода, поэтому её было очень легко понимать и менять. Common Lisp, который мы использовали, CLisp, сам работает поверх интерпретатора байт-кода. То есть у нас было два уровня интерпретации, один из них (верхний) шокирующе неэффективный, и язык был пригоден к использованию. Едва пригоден, признаю, но пригоден.

Writing software as multiple layers is a powerful technique
even within applications. Bottom-up programming means writing
a program as a series of layers, each of which serves as a
language for the one above. This approach tends to yield
smaller, more flexible programs. It's also the best route to
that holy grail, reusability. A language is by definition
reusable. The more
of your application you can push down into a language for writing
that type of application, the more of your software will be
reusable.

Писать ПО в виде нескольких слоёв — мощный приём даже внутри приложений. Программирование снизу вверх означает писать программу как серию слоёв, каждый из которых служит языком для слоя выше. Этот подход обычно даёт меньшие и более гибкие программы. Это также лучший путь к тому Святому Граалю — переиспользуемости. Язык по определению переиспользуем. Чем большую часть вашего приложения вы можете протолкнуть вниз в язык для написания приложений такого типа, тем большая часть вашего софта будет переиспользуема.

Somehow the idea of reusability got attached
to object-oriented programming in the 1980s, and no amount of
evidence to the contrary seems to be able to shake it free. But
although some object-oriented software is reusable, what makes
it reusable is its bottom-upness, not its object-orientedness.
Consider libraries: they're reusable because they're language,
whether they're written in an object-oriented style or not.

Каким-то образом идея переиспользуемости в 1980-х оказалась прицеплена к объектно-ориентированному программированию, и никакого количества доказательств обратного, похоже, недостаточно, чтобы оторвать её. Но хотя часть объектно-ориентированного ПО действительно переиспользуема, переиспользуемой её делает её устроенность снизу вверх, а не объектная ориентированность. Возьмите библиотеки: они переиспользуемы потому, что они — язык, написаны они в объектно-ориентированном стиле или нет.

I don't predict the demise of object-oriented programming, by the
way. Though I don't think it has much to offer good programmers,
except in certain specialized domains, it is irresistible to
large organizations. Object-oriented programming
offers a sustainable way to write spaghetti code. It lets you accrete
programs as a series of patches.

Кстати, я не предсказываю гибель объектно-ориентированного программирования. Хотя я не думаю, что оно много даёт хорошим программистам, кроме как в некоторых специализированных областях, оно неотразимо для больших организаций. Объектно-ориентированное программирование предлагает устойчивый способ писать спагетти-код. Оно позволяет наращивать программы как серию заплаток.

Large organizations
always tend to develop software this way, and I expect this
to be as true in a hundred years as it is today.

Большие организации всегда склонны разрабатывать ПО именно так, и я ожидаю, что через сто лет это будет так же верно, как и сегодня.

As long as we're talking about the future, we had better
talk about parallel computation, because that's where this
idea seems to live. That is, no matter when you're talking, parallel
computation seems to be something that is going to happen
in the future.

Раз уж мы говорим о будущем, нам лучше поговорить о параллельных вычислениях, потому что именно там, похоже, обитает эта идея. То есть, в какой бы момент вы ни говорили, параллельные вычисления, кажется, — это то, что произойдёт в будущем.

Will the future ever catch up with it? People have been
talking about parallel computation as something imminent
for at least 20
years, and it hasn't affected programming practice much so far.
Or hasn't it? Already
chip designers have to think about it, and so must
people trying to write systems software on multi-cpu computers.

Догонит ли когда-нибудь будущее эту идею? Люди говорят о параллельных вычислениях как о чём-то неизбежно близком как минимум 20 лет, и пока что они не сильно повлияли на практику программирования. Или повлияли? Дизайнерам чипов уже приходится об этом думать, как и тем, кто пишет системное ПО для многопроцессорных компьютеров.

The real question is, how far up the ladder of abstraction will
parallelism go?
In a hundred years will it affect even application programmers? Or
will it be something that compiler writers think about, but
which is usually invisible in the source code of applications?

Реальный вопрос в том, насколько высоко по лестнице абстракции поднимется параллелизм. Затронет ли он через сто лет даже прикладных программистов? Или это будет то, о чём думают разработчики компиляторов, но что обычно невидимо в исходном коде приложений?

One thing that does seem likely is that most opportunities for
parallelism will be wasted. This is a special case of my more
general prediction that most of the extra computer power we're
given will go to waste. I expect that, as with the stupendous
speed of the underlying hardware, parallelism will be something
that is available if you ask for it explicitly, but ordinarily
not used. This implies that the kind of parallelism we have in
a hundred years will not, except in special applications, be
massive parallelism. I expect for
ordinary programmers it will be more like being able to fork off
processes that all end up running in parallel.

Одно, что кажется вероятным, — большая часть возможностей для параллелизма будет растрачена впустую. Это частный случай моего более общего предсказания, что бóльшая часть лишней вычислительной мощности, которую нам дадут, уйдёт впустую. Я думаю, что, как и с потрясающей скоростью лежащего в основе железа, параллелизм будет чем-то, что доступно, если явно его попросить, но обычно не используется. Это значит, что параллелизм, который будет у нас через сто лет, за исключением специальных приложений, не будет массовым параллелизмом. Я думаю, для обычных программистов это будет скорее возможность форкнуть несколько процессов, которые в итоге выполняются параллельно.

And this will, like asking for specific implementations of data
structures, be something that you do fairly late in the life of a
program, when you try to optimize it. Version 1s will ordinarily
ignore any advantages to be got from parallel computation, just
as they will ignore advantages to be got from specific representations
of data.

И это, как и запрос конкретных реализаций структур данных, будет тем, что вы делаете довольно поздно в жизни программы, пытаясь её оптимизировать. Версии 1 обычно будут игнорировать любые выгоды, которые можно получить от параллельных вычислений, точно так же, как они будут игнорировать выгоды от конкретных представлений данных.

Except in special kinds of applications, parallelism won't
pervade the programs that are written in a hundred years. It would be
premature optimization if it did.

За исключением специальных типов приложений, через сто лет параллелизм не будет пронизывать пишущиеся программы. Если бы это было так, это было бы преждевременной оптимизацией.

How many programming languages will there
be in a hundred years? There seem to be a huge number of new
programming languages lately. Part of the reason is that
faster hardware has allowed programmers to make different
tradeoffs between speed and convenience, depending on the
application. If this is a real trend, the hardware we'll
have in a hundred years should only increase it.

Сколько языков программирования будет через сто лет? В последнее время вроде бы появилось огромное количество новых языков программирования. Отчасти причина в том, что более быстрое железо позволило программистам делать разные компромиссы между скоростью и удобством, в зависимости от приложения. Если это реальный тренд, то железо, которое будет у нас через сто лет, должно лишь усилить его.

And yet there may be only a few widely-used languages in a
hundred years. Part of the reason I say this
is optimism: it seems that, if you did a really good job,
you could make a language that was ideal for writing a
slow version 1, and yet with the right optimization advice
to the compiler, would also yield very fast code when necessary.
So, since I'm optimistic, I'm going to predict that despite
the huge gap they'll have between acceptable and maximal
efficiency, programmers in a hundred years will have languages
that can span most of it.

И всё же через сто лет, возможно, будет лишь несколько широко используемых языков. Отчасти я это говорю из оптимизма: похоже, что при действительно хорошей работе можно сделать язык, идеально подходящий для написания медленной версии 1 и при этом при правильных подсказках компилятору для оптимизации выдающий и очень быстрый код, когда это нужно. Так что, поскольку я оптимист, предскажу, что, несмотря на огромный разрыв между приемлемой и максимальной эффективностью, у программистов через сто лет будут языки, способные покрыть большую его часть.

As this gap widens, profilers will become increasingly important.
Little attention is paid to profiling now. Many people still
seem to believe that the way to get fast applications is to
write compilers that generate fast code. As the gap between
acceptable and maximal performance widens, it will become
increasingly clear that the way to get fast applications is
to have a good guide from one to the other.

По мере того как этот разрыв расширяется, профилировщики будут становиться всё более важными. Сейчас профилированию уделяют мало внимания. Многие, похоже, до сих пор считают, что способ получить быстрые приложения — писать компиляторы, генерирующие быстрый код. По мере расширения разрыва между приемлемой и максимальной производительностью будет становиться всё яснее, что способ получить быстрые приложения — иметь хорошего проводника от одной к другой.

When I say there may only be a few languages, I'm not including
domain-specific "little languages". I think such embedded languages
are a great idea, and I expect them to proliferate. But I expect
them to be written as thin enough skins that users can see
the general-purpose language underneath.

Когда я говорю, что языков, возможно, будет немного, я не включаю сюда предметно-ориентированные «маленькие языки». Я думаю, такие встроенные языки — отличная идея, и ожидаю их распространения. Но я ожидаю, что они будут написаны достаточно тонкой обёрткой, чтобы пользователи видели через неё язык общего назначения.

Who will design the languages of the future? One of the most exciting
trends in the last ten years has been the rise of open-source
languages like Perl, Python, and Ruby.
Language design is being taken over by hackers. The results
so far are messy, but encouraging. There are some stunningly
novel ideas in Perl, for example. Many are stunningly bad, but
that's always true of ambitious efforts. At its current rate
of mutation, God knows what Perl might evolve into in a hundred
years.

Кто будет проектировать языки будущего? Один из самых увлекательных трендов последних десяти лет — рост языков с открытым исходным кодом, таких как Perl, Python и Ruby. Дизайн языков переходит к хакерам. Результаты пока что беспорядочные, но обнадёживающие. В Perl, например, есть несколько ошеломительно новых идей. Многие из них ошеломительно плохи, но так всегда бывает с амбициозными попытками. При нынешнем темпе мутаций бог знает, во что Perl сможет эволюционировать за сто лет.

It's not true that those who can't do, teach (some of the best
hackers I know are professors), but it is true that there are a
lot of things that those who teach can't do. Research imposes
constraining caste restrictions. In any academic
field there are topics that are ok to work on and others that
aren't. Unfortunately the distinction between acceptable and
forbidden topics is usually based on how intellectual
the work sounds when described in research papers, rather than
how important it is for getting good results. The extreme case
is probably literature; people studying literature rarely
say anything that would be of the slightest use to those
producing it.

Неправда, что «кто не умеет делать — учит» (некоторые из лучших известных мне хакеров — профессора), но правда то, что есть много вещей, которые те, кто учит, делать не могут. Исследовательская работа накладывает сковывающие кастовые ограничения. В любой академической области есть темы, которыми можно заниматься, и темы, которыми нельзя. К сожалению, различие между допустимыми и запрещёнными темами обычно основано на том, насколько интеллектуально звучит работа в описании в исследовательских статьях, а не на том, насколько она важна для получения хороших результатов. Крайний случай — это, пожалуй, литература; люди, изучающие литературу, редко говорят что-то, что было бы хоть сколько-нибудь полезно тем, кто её создаёт.

Though the situation is better in the sciences,
the overlap between the kind of work you're allowed to do and the
kind of work that yields good languages is distressingly small.
(Olin Shivers has grumbled eloquently
about this.) For example, types seem to be an inexhaustible source
of research papers, despite the fact that static typing
seems to preclude true macros-- without which, in my opinion, no
language is worth using.

Хотя в естественных науках ситуация лучше, перекрытие между тем, чем разрешается заниматься, и тем, что даёт хорошие языки, удручающе мало. (Olin Shivers красноречиво поворчал об этом.) Например, типы, похоже, неиссякаемый источник исследовательских статей, несмотря на то что статическая типизация, кажется, исключает настоящие макросы — без которых, по моему мнению, ни один язык не стоит использования.

The trend is not merely toward languages being developed
as open-source projects rather than "research", but toward
languages being designed by the application programmers who need
to use them, rather than by compiler writers. This seems a good
trend and I expect it to continue.

Тенденция не только в том, что языки развиваются как open-source проекты, а не как «исследования», но и в том, что языки проектируются прикладными программистами, которым нужно ими пользоваться, а не разработчиками компиляторов. Это, похоже, хороший тренд, и я ожидаю его продолжения.

Unlike physics in a hundred years, which is almost necessarily
impossible to predict, I think it may be possible in principle
to design a language now that would appeal to users in a hundred
years.

В отличие от физики через сто лет, которую почти наверняка невозможно предсказать, я думаю, что в принципе можно уже сейчас спроектировать язык, который понравится пользователям через сто лет.

One way to design a language is to just write down the program
you'd like to be able to write, regardless of whether there
is a compiler that can translate it or hardware that can run it.
When you do this you can assume unlimited resources. It seems
like we ought to be able to imagine unlimited resources as well
today as in a hundred years.

Один из способов проектировать язык — просто записать программу, которую вы хотели бы иметь возможность написать, независимо от того, есть ли компилятор, который сможет её перевести, или железо, которое сможет её запустить. Так можно предполагать неограниченные ресурсы. Кажется, мы должны быть способны представлять себе неограниченные ресурсы сегодня не хуже, чем через сто лет.

What program would one like to write? Whatever is least work.
Except not quite: whatever would be least work if your ideas about
programming weren't already influenced by the languages you're
currently used to. Such influence can be so pervasive that
it takes a great effort to overcome it. You'd think it would
be obvious to creatures as lazy as us how to express a program
with the least effort. In fact, our ideas about what's possible
tend to be so limited by whatever language we think in that
easier formulations of programs seem very surprising. They're
something you have to discover, not something you naturally
sink into.

Какую программу хотелось бы написать? Какую угодно, лишь бы поменьше работы. Не совсем так: какую угодно, с какой было бы меньше всего работы, если бы ваши представления о программировании не были уже сформированы языками, к которым вы сейчас привыкли. Такое влияние может быть настолько всепроникающим, что преодолеть его требует огромных усилий. Казалось бы, столь ленивым существам, как мы, должно быть очевидно, как выразить программу с минимальными усилиями. На деле же наши представления о возможном настолько ограничены языком, на котором мы думаем, что более простые формулировки программ кажутся очень удивительными. Это то, что приходится открывать, а не то, во что естественно сваливаешься.

One helpful trick here
is to use the length of the program as an approximation for
how much work it is to write. Not the length in characters,
of course, but the length in distinct syntactic elements-- basically,
the size of the parse tree. It may not be quite true that
the shortest program is the least work to write, but it's
close enough that you're better off aiming for the solid
target of brevity than the fuzzy, nearby one of least work.
Then the algorithm for language design becomes: look at a program
and ask, is there any way to write this that's shorter?

Один полезный приём здесь — использовать длину программы как приближение к тому, сколько труда нужно для её написания. Не длину в символах, конечно, а длину в различимых синтаксических элементах — по сути, размер дерева разбора. Может быть, не совсем верно, что самая короткая программа — это та, на которую нужно меньше всего труда, но это достаточно близко, чтобы вам лучше было целиться в твёрдую мишень краткости, чем в близкую, но размытую мишень минимума труда. Тогда алгоритм для проектирования языка становится таким: посмотри на программу и спроси, есть ли способ записать её короче?

In practice, writing programs in an imaginary hundred-year
language will work to varying degrees depending
on how close you are to the core. Sort routines you can
write now. But it would be
hard to predict now what kinds of libraries might be needed in
a hundred years. Presumably many libraries will be for domains that
don't even exist yet. If SETI@home works, for example, we'll
need libraries for communicating with aliens. Unless of course
they are sufficiently advanced that they already communicate
in XML.

На практике написание программ на воображаемом столетнем языке будет работать в разной степени в зависимости от того, насколько вы близки к ядру. Процедуры сортировки можно написать уже сейчас. Но какие библиотеки могут понадобиться через сто лет, сейчас было бы трудно предсказать. Многие библиотеки, надо полагать, будут для предметных областей, которых ещё даже не существует. Если SETI@home сработает, например, нам понадобятся библиотеки для общения с инопланетянами. Если, конечно, они не настолько продвинутые, что уже общаются в XML.

At the other extreme, I think you might be able to design the
core language today. In fact, some might argue that it was already
mostly designed in 1958.

С другой стороны, я думаю, что ядро языка может быть спроектировано уже сегодня. Более того, кое-кто мог бы возразить, что оно в основном уже было спроектировано в 1958 году.

If the hundred year language were available today, would we
want to program in it? One way to answer this question is to
look back. If present-day programming languages had been available
in 1960, would anyone have wanted to use them?

Если бы столетний язык был доступен сегодня, захотели бы мы на нём программировать? Один из способов ответить на этот вопрос — оглянуться назад. Если бы современные языки программирования были доступны в 1960 году, захотел ли бы кто-нибудь ими пользоваться?

In some ways, the answer is no. Languages today assume
infrastructure that didn't exist in 1960. For example, a language
in which indentation is significant, like Python, would not
work very well on printer terminals. But putting such problems
aside-- assuming, for example, that programs were all just
written on paper-- would programmers of the 1960s have liked
writing programs in the languages we use now?

В каком-то смысле ответ — нет. Современные языки предполагают инфраструктуру, которой не было в 1960-м. Например, язык, в котором значимы отступы, как Python, не очень хорошо работал бы на принтерных терминалах. Но, отложив такие проблемы в сторону — предположив, например, что программы писались бы все просто на бумаге — понравилось ли бы программистам 1960-х годов писать программы на тех языках, которые мы используем сейчас?

I think so.
Some of the less imaginative ones,
who had artifacts of early languages built into their ideas of
what a program was, might have had trouble. (How can you manipulate
data without doing pointer arithmetic? How can you implement
flow charts without gotos?) But I think the smartest programmers
would have had no trouble making the most of present-day
languages, if they'd had them.

Я думаю, да. У некоторых, менее воображаемых, с артефактами ранних языков, встроенными в их представления о том, что такое программа, могли быть проблемы. (Как можно манипулировать данными, не занимаясь арифметикой указателей? Как реализовывать блок-схемы без goto?) Но я думаю, что самые умные программисты не имели бы никаких проблем с тем, чтобы извлечь максимум из современных языков, если бы они у них были.

If we had the hundred-year language now, it would at least make a
great pseudocode. What about using it to write software?
Since the hundred-year language
will need to generate fast code for some applications, presumably
it could generate code efficient enough to run acceptably well
on our hardware. We might have to give more optimization advice
than users in a hundred years, but it still might be a net win.

Если бы столетний язык был у нас сейчас, он, как минимум, был бы прекрасным псевдокодом. А что насчёт использования его для написания софта? Поскольку столетнему языку нужно будет генерировать быстрый код для некоторых приложений, по всей видимости, он мог бы генерировать код, достаточно эффективный, чтобы приемлемо работать на нашем железе. Возможно, нам пришлось бы давать больше подсказок для оптимизации, чем пользователям через сто лет, но это всё равно могло бы быть чистым выигрышем.

Now we have two ideas that, if you combine them, suggest interesting
possibilities: (1) the hundred-year language could, in principle, be
designed today, and (2) such a language, if it existed, might be good to
program in today. When you see these ideas laid out like that,
it's hard not to think, why not try writing the hundred-year language
now?

Теперь у нас есть две идеи, которые, если их соединить, предполагают интересные возможности: (1) столетний язык в принципе мог бы быть спроектирован сегодня, и (2) такой язык, если бы он существовал, мог бы быть хорош для программирования сегодня. Когда видишь эти идеи рядом, трудно не подумать: а почему бы не попробовать написать столетний язык прямо сейчас?

When you're working on language design, I think it is good to
have such a target and to keep it consciously in mind. When you
learn to drive, one of the principles they teach you is to
align the car not by lining up the hood with the stripes painted
on the road, but by aiming at some point in the distance. Even
if all you care about is what happens in the next ten feet, this
is the right answer. I
think we can and should do the same thing with programming languages.

Когда работаешь над дизайном языка, думаю, полезно иметь такую цель и сознательно держать её в уме. Когда учишься водить, один из принципов, которым вас учат — выравнивать машину не по линии капота относительно нарисованных на дороге полос, а целясь в какую-то точку вдали. Даже если вас волнует только то, что случится в ближайшие десять футов, это правильный ответ. Думаю, мы можем и должны делать то же самое с языками программирования.

Notes

Примечания

I believe Lisp Machine Lisp was the first language to embody
the principle that declarations (except those of dynamic variables)
were merely optimization advice,
and would not change the meaning of a correct program. Common Lisp
seems to have been the first to state this explicitly.

Я полагаю, Lisp Machine Lisp был первым языком, воплотившим принцип, что объявления (за исключением объявлений динамических переменных) — это всего лишь подсказки для оптимизации и не меняют смысла корректной программы. Common Lisp, кажется, был первым, кто заявил это явно.

Thanks to Trevor Blackwell, Robert Morris, and Dan Giffin for
reading drafts of this, and to Guido van Rossum, Jeremy Hylton, and the
rest of the Python crew for inviting me to speak at PyCon.

Спасибо Trevor Blackwell, Robert Morris и Dan Giffin за чтение черновиков, а также Guido van Rossum, Jeremy Hylton и остальной команде Python за приглашение выступить на PyCon.