Five Questions about Language Design

May 2001

Май 2001

(These are some notes I made
for a panel discussion on programming language design
at MIT on May 10, 2001.)

(Это заметки, которые я подготовил для панельной дискуссии о проектировании языков программирования в MIT 10 мая 2001 года.)

1. Programming Languages Are for People.

1. Языки программирования — для людей.

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.

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

2. Design for Yourself and Your Friends.

2. Проектируй для себя и своих друзей.

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.

Когда языки проектируются для других, это всегда конкретная группа других: люди, не такие умные, как создатель языка. В итоге получается язык, который разговаривает с вами свысока. Cobol — крайний случай, но этим духом пронизаны многие языки.

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.

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

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.

3. Дай программисту максимум контроля.

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.

Когда я впервые изучил Lisp, больше всего мне понравилось то, что он считал меня равным партнёром. Во всех других языках, которые я знал до этого, были язык и моя программа, написанная на этом языке, и они были чётко разделены. Но в Lisp функции и макросы, которые я писал, ничем не отличались от тех, из которых состоял сам язык. Я мог переписать язык, если хотел. В этом была та же притягательность, что и в open-source софте.

4. Aim for Brevity.

4. Стремись к краткости.

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.

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

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.

5. Признай, чем является хакерство.

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?

1. Как организовать большие библиотеки?

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.

Библиотеки становятся всё более важной частью языков программирования. Они также становятся больше, и это может быть опасно. Если поиск нужной библиотечной функции занимает больше времени, чем написание её с нуля, весь этот код лишь делает ваше руководство толще. (Документация Symbolics была наглядным примером.) Поэтому я думаю, что нам придётся работать над способами организации библиотек. В идеале их нужно проектировать так, чтобы программист мог угадать, какой вызов библиотеки сделает то, что нужно.

2. Are People Really Scared of Prefix Syntax?

2. Люди действительно боятся префиксного синтаксиса?

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.

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

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

3. Что нужно для серверного софта?

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.

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

4. What New Abstractions Are Left to Discover?

4. Какие новые абстракции ещё предстоит открыть?

I'm not sure how
reasonable a hope this is, but one thing I would really love to
do, personally, is discover a new abstraction-- something that would
make as much of a difference as having first class functions or
recursion or even keyword parameters. This may be an impossible
dream. These things don't get discovered that often. But I am always
looking.

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

1. You Can Use Whatever Language You Want.

1. Вы можете использовать любой язык.

Writing application
programs used to mean writing desktop software. And in desktop
software there is a big bias toward writing the application in the
same language as the operating system. And so ten years ago,
writing software pretty much meant writing software in C.
Eventually a tradition evolved:
application programs must not be written in unusual languages.
And this tradition had so long to develop that nontechnical people
like managers and venture capitalists also learned it.

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

Server-based software blows away this whole model. With server-based
software you can use any language you want. Almost nobody understands
this yet (especially not managers and venture capitalists).
A few hackers understand it, and that's why we even hear
about new, indy languages like Perl and Python. We're not hearing
about Perl and Python because people are using them to write Windows
apps.

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

What this means for us, as people interested in designing programming
languages, is that there is now potentially an actual audience for
our work.

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

2. Speed Comes from Profilers.

2. Скорость обеспечивают профилировщики.

Language designers, or at least
language implementors, like to write compilers that generate fast
code. But I don't think this is what makes languages fast for users.
Knuth pointed out long ago that speed only matters in a few critical
bottlenecks. And anyone who's tried it knows that you can't guess
where these bottlenecks are. Profilers are the answer.

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

Language designers are solving the wrong problem. Users don't need
benchmarks to run fast. What they need is a language that can show
them what parts of their own programs need to be rewritten. That's
where speed comes from in practice. So maybe it would be a net
win if language implementors took half the time they would
have spent doing compiler optimizations and spent it writing a
good profiler instead.

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

3. You Need an Application to Drive the Design of a Language.

3. Для проектирования языка нужно приложение, которое его двигает.

This may not be an absolute rule, but it seems like the best languages
all evolved together with some application they were being used to
write. C was written by people who needed it for systems programming.
Lisp was developed partly to do symbolic differentiation, and
McCarthy was so eager to get started that he was writing differentiation
programs even in the first paper on Lisp, in 1960.

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

It's especially good if your application solves some new problem.
That will tend to drive your language to have new features that
programmers need. I personally am interested in writing
a language that will be good for writing server-based applications.

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

[During the panel, Guy Steele also made this point, with the
additional suggestion that the application should not consist of
writing the compiler for your language, unless your language
happens to be intended for writing compilers.]

[Во время дискуссии Guy Steele также высказал эту мысль, добавив, что приложением не должно быть написание компилятора для вашего языка — если только ваш язык не предназначен специально для написания компиляторов.]

4. A Language Has to Be Good for Writing Throwaway Programs.

4. Язык должен быть хорош для написания одноразовых программ.

You know what a throwaway program is: something you write quickly for
some limited task. I think if you looked around you'd find that
a lot of big, serious programs started as throwaway programs. I
would not be surprised if most programs started as throwaway
programs. And so if you want to make a language that's good for
writing software in general, it has to be good for writing throwaway
programs, because that is the larval stage of most software.

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

5. Syntax Is Connected to Semantics.

5. Синтаксис связан с семантикой.

It's traditional to think of
syntax and semantics as being completely separate. This will
sound shocking, but it may be that they aren't.
I think that what you want in your language may be related
to how you express it.

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

I was talking recently to Robert Morris, and he pointed out that
operator overloading is a bigger win in languages with infix
syntax. In a language with prefix syntax, any function you define
is effectively an operator. If you want to define a plus for a
new type of number you've made up, you can just define a new function
to add them. If you do that in a language with infix syntax,
there's a big difference in appearance between the use of an
overloaded operator and a function call.

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

1. New Programming Languages.

1. Новые языки программирования.

Back in the 1970s
it was fashionable to design new programming languages. Recently
it hasn't been. But I think server-based software will make new
languages fashionable again. With server-based software, you can
use any language you want, so if someone does design a language that
actually seems better than others that are available, there will be
people who take a risk and use it.

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

2. Time-Sharing.

2. Разделение времени.

Richard Kelsey gave this as an idea whose time
has come again in the last panel, and I completely agree with him.
My guess (and Microsoft's guess, it seems) is that much computing
will move from the desktop onto remote servers. In other words,
time-sharing is back. And I think there will need to be support
for it at the language level. For example, I know that Richard
and Jonathan Rees have done a lot of work implementing process
scheduling within Scheme 48.

Richard Kelsey назвал это идеей, время которой снова пришло, на предыдущей панели, и я полностью с ним согласен. Моё предположение (и, похоже, предположение Microsoft) — что значительная часть вычислений переместится с десктопов на удалённые серверы. Иными словами, разделение времени возвращается. И я думаю, что потребуется поддержка этого на уровне языка. Например, я знаю, что Richard и Jonathan Rees проделали большую работу по реализации планирования процессов внутри Scheme 48.

3. Efficiency.

3. Эффективность.

Recently it was starting to seem that computers
were finally fast enough. More and more we were starting to hear
about byte code, which implies to me at least that we feel we have
cycles to spare. But I don't think we will, with server-based
software. Someone is going to have to pay for the servers that
the software runs on, and the number of users they can support per
machine will be the divisor of their capital cost.

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

So I think efficiency will matter, at least in computational
bottlenecks. It will be especially important to do i/o fast,
because server-based applications do a lot of i/o.

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

It may turn out that byte code is not a win, in the end. Sun and
Microsoft seem to be facing off in a kind of a battle of the byte
codes at the moment. But they're doing it because byte code is a
convenient place to insert themselves into the process, not because
byte code is in itself a good idea. It may turn out that this
whole battleground gets bypassed. That would be kind of amusing.

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

1. Clients.

1. Клиенты.

This is just a guess, but my guess is that
the winning model for most applications will be purely server-based.
Designing software that works on the assumption that everyone will
have your client is like designing a society on the assumption that
everyone will just be honest. It would certainly be convenient, but
you have to assume it will never happen.

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

I think there will be a proliferation of devices that have some
kind of Web access, and all you'll be able to assume about them is
that they can support simple html and forms. Will you have a
browser on your cell phone? Will there be a phone in your palm
pilot? Will your blackberry get a bigger screen? Will you be able
to browse the Web on your gameboy? Your watch? I don't know.
And I don't have to know if I bet on
everything just being on the server. It's
just so much more robust to have all the
brains on the server.

Я думаю, появится множество устройств с тем или иным доступом к вебу, и единственное, что можно будет о них предполагать, — это поддержка простого HTML и форм. Будет ли у вас браузер на мобильном телефоне? Будет ли телефон в вашем Palm Pilot? Станет ли экран вашего BlackBerry больше? Сможете ли вы выходить в интернет с Game Boy? С часов? Не знаю. И мне не нужно знать, если я ставлю на то, что всё будет на сервере. Это просто гораздо надёжнее — держать все мозги на сервере.

2. Object-Oriented Programming.

2. Объектно-ориентированное программирование.

I realize this is a
controversial one, but I don't think object-oriented programming
is such a big deal. I think it is a fine model for certain kinds
of applications that need that specific kind of data structure,
like window systems, simulations, and cad programs. But I don't
see why it ought to be the model for all programming.

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

I think part of the reason people in big companies like object-oriented
programming is because it yields a lot of what looks like work.
Something that might naturally be represented as, say, a list of
integers, can now be represented as a class with all kinds of
scaffolding and hustle and bustle.

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

Another attraction of
object-oriented programming is that methods give you some of the
effect of first class functions. But this is old news to Lisp
programmers. When you have actual first class functions, you can
just use them in whatever way is appropriate to the task at hand,
instead of forcing everything into a mold of classes and methods.

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

What this means for language design, I think, is that you shouldn't
build object-oriented programming in too deeply. Maybe the
answer is to offer more general, underlying stuff, and let people design
whatever object systems they want as libraries.

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

3. Design by Committee.

3. Проектирование комитетом.

Having your language designed by a committee is a big pitfall,
and not just for the reasons everyone knows about. Everyone
knows that committees tend to yield lumpy, inconsistent designs.
But I think a greater danger is that they won't take risks.
When one person is in charge he can take risks
that a committee would never agree on.

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

Is it necessary to take risks to design a good language though?
Many people might suspect
that language design is something where you should stick fairly
close to the conventional wisdom. I bet this isn't true.
In everything else people do, reward is proportionate to risk.
Why should language design be any different?

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