Why Arc Isn't Especially Object-Oriented
Пол Грэм объясняет, почему язык Arc не делает ставку на объектно-ориентированное программирование. Он считает ООП полезным в отдельных случаях, но не обязательным подходом для каждой программы. Автор выделяет пять причин популярности ООП и считает три с половиной из них несостоятельными: компенсация ограничений статически типизированных языков без замыканий и макросов, дисциплина для больших команд средних программистов в крупных компаниях, видимость объёма работы и расширяемость языка через классы. Сам Грэм за годы работы на Common Lisp ни разу не воспользовался мощной системой CLOS, решая аналогичные задачи через хеш-таблицы с замыканиями. Он признаёт риск проектировать язык по личному опыту, но считает ещё более опасным добавлять то, что никогда не было нужно, лишь потому, что это принято считать хорошей идеей.
There is a kind of mania for object-oriented programming at the moment, but
Сейчас наблюдается своего рода мания вокруг объектно-ориентированного программирования, но
some of the smartest programmers I know are some of the least excited about it.
некоторые из самых толковых программистов, которых я знаю, относятся к нему с наименьшим энтузиазмом.
My own feeling is that object-oriented
programming is a useful technique in some
cases, but it isn't something that has to pervade every program you
write. You should be able to define new types,
but you shouldn't have to express every program as the
definition of new types.
Моё личное ощущение таково, что объектно-ориентированное программирование — полезный приём в некоторых случаях, но это не то, чем должна быть пронизана каждая программа, которую вы пишете. У вас должна быть возможность определять новые типы, но вы не должны быть обязаны выражать каждую программу как определение новых типов.
I think there are five reasons people like object-oriented
programming, and three and a half of them are bad:
Я думаю, есть пять причин, по которым людям нравится объектно-ориентированное программирование, и три с половиной из них — плохие:
Object-oriented programming is exciting
if you have a statically-typed language without
lexical closures or macros. To some degree, it offers a way around these
limitations. (See Greenspun's Tenth Rule.)
Объектно-ориентированное программирование выглядит привлекательно, если у вас статически типизированный язык без лексических замыканий и макросов. В какой-то мере оно предлагает способ обойти эти ограничения. (См. Десятое правило Гринспена.)
Object-oriented programming is popular in big companies,
because it suits the way they write software. At big companies,
software tends to be written by large (and frequently changing)
teams of
mediocre programmers. Object-oriented programming imposes a
discipline on these programmers that prevents any one of them
from doing too much damage. The price is that the resulting
code is bloated with protocols and full of duplication.
This is not too high a price for big companies, because their
software is probably going to be bloated and full of
duplication anyway.
Объектно-ориентированное программирование популярно в крупных компаниях, потому что оно соответствует тому, как они пишут программное обеспечение. В больших компаниях ПО обычно пишут большие (и часто меняющиеся) команды посредственных программистов. Объектно-ориентированное программирование навязывает таким программистам дисциплину, которая не даёт никому из них нанести слишком большого ущерба. Цена этого — раздутый код, перегруженный протоколами и полный дублирования. Для крупных компаний цена не слишком высока, потому что их ПО, скорее всего, всё равно будет раздутым и полным дублирования.
Object-oriented
programming generates a lot of what looks like work.
Back in the days of fanfold, there was a type of programmer who
would only put five or ten lines of code on a page, preceded
by twenty lines of elaborately formatted comments.
Object-oriented programming is like crack for these people: it lets
you incorporate all this scaffolding right into your source
code. Something that a Lisp hacker might handle by pushing
a symbol onto a list becomes a whole file of classes and
methods. So it is a good tool if you want to convince yourself,
or someone else, that you are doing a lot of work.
Объектно-ориентированное программирование порождает много того, что выглядит как работа. В эпоху фальцованной бумаги был тип программиста, который умещал на странице всего пять-десять строк кода, предварённых двадцатью строками тщательно отформатированных комментариев. Объектно-ориентированное программирование для таких людей — как наркотик: оно позволяет вписать все эти строительные леса прямо в исходный код. То, что Lisp-хакер мог бы решить, добавив символ в список, превращается в целый файл классов и методов. Так что это хороший инструмент, если вы хотите убедить себя или кого-то ещё, что выполняете большую работу.
If a language is itself an object-oriented program, it can
be extended by users. Well, maybe. Or maybe you can do
even better by offering the sub-concepts
of object-oriented programming a la carte. Overloading,
for example, is not intrinsically tied to classes. We'll see.
Если язык сам по себе является объектно-ориентированной программой, его могут расширять пользователи. Ну, может быть. А может быть, вы добьётесь даже большего, предлагая подконцепции объектно-ориентированного программирования по отдельности. Перегрузка, например, изначально не связана с классами. Посмотрим.
Object-oriented abstractions map neatly onto the domains
of certain specific kinds of programs, like simulations and CAD
systems.
Объектно-ориентированные абстракции аккуратно ложатся на предметные области определённых видов программ — таких как симуляции и CAD-системы.
I personally have never needed object-oriented abstractions.
Common Lisp has an enormously powerful object system and I've
never used it once. I've done a lot of things (e.g. making
hash tables full of closures) that would have required
object-oriented techniques to do in wimpier languages, but
I have never had to use CLOS.
Лично мне объектно-ориентированные абстракции никогда не были нужны. У Common Lisp есть невероятно мощная объектная система, и я ни разу ею не воспользовался. Я делал множество вещей (например, создавал хеш-таблицы, заполненные замыканиями), для которых в более слабых языках потребовались бы объектно-ориентированные приёмы, но мне ни разу не пришлось применить CLOS.
Maybe I'm just stupid, or have worked on some limited subset
of applications. There is a danger in designing a language
based on one's own experience of programming. But it seems
more dangerous to put stuff in that you've never needed
because it's thought to be a good idea.
Может быть, я просто туп или работал лишь над неким ограниченным подмножеством приложений. Есть опасность проектировать язык, исходя из собственного опыта программирования. Но ещё опаснее, как мне кажется, включать в него то, что вам никогда не было нужно, только потому, что это считается хорошей идеей.