Why Arc Isn't Especially Object-Oriented
Пол Грэм объясняет, почему язык Arc не делает ставку на объектно-ориентированное программирование. Он считает ООП полезным в отдельных случаях, но не обязательным подходом для каждой программы. Автор выделяет пять причин популярности ООП и считает три с половиной из них несостоятельными: компенсация ограничений статически типизированных языков без замыканий и макросов, дисциплина для больших команд средних программистов в крупных компаниях, видимость объёма работы и расширяемость языка через классы. Сам Грэм за годы работы на Common Lisp ни разу не воспользовался мощной системой CLOS, решая аналогичные задачи через хеш-таблицы с замыканиями. Он признаёт риск проектировать язык по личному опыту, но считает ещё более опасным добавлять то, что никогда не было нужно, лишь потому, что это принято считать хорошей идеей.
Сейчас наблюдается своего рода мания вокруг объектно-ориентированного программирования, но
некоторые из самых толковых программистов, которых я знаю, относятся к нему с наименьшим энтузиазмом.
Моё личное ощущение таково, что объектно-ориентированное программирование — полезный приём в некоторых случаях, но это не то, чем должна быть пронизана каждая программа, которую вы пишете. У вас должна быть возможность определять новые типы, но вы не должны быть обязаны выражать каждую программу как определение новых типов.
Я думаю, есть пять причин, по которым людям нравится объектно-ориентированное программирование, и три с половиной из них — плохие:
Объектно-ориентированное программирование выглядит привлекательно, если у вас статически типизированный язык без лексических замыканий и макросов. В какой-то мере оно предлагает способ обойти эти ограничения. (См. Десятое правило Гринспена.)
Объектно-ориентированное программирование популярно в крупных компаниях, потому что оно соответствует тому, как они пишут программное обеспечение. В больших компаниях ПО обычно пишут большие (и часто меняющиеся) команды посредственных программистов. Объектно-ориентированное программирование навязывает таким программистам дисциплину, которая не даёт никому из них нанести слишком большого ущерба. Цена этого — раздутый код, перегруженный протоколами и полный дублирования. Для крупных компаний цена не слишком высока, потому что их ПО, скорее всего, всё равно будет раздутым и полным дублирования.
Объектно-ориентированное программирование порождает много того, что выглядит как работа. В эпоху фальцованной бумаги был тип программиста, который умещал на странице всего пять-десять строк кода, предварённых двадцатью строками тщательно отформатированных комментариев. Объектно-ориентированное программирование для таких людей — как наркотик: оно позволяет вписать все эти строительные леса прямо в исходный код. То, что Lisp-хакер мог бы решить, добавив символ в список, превращается в целый файл классов и методов. Так что это хороший инструмент, если вы хотите убедить себя или кого-то ещё, что выполняете большую работу.
Если язык сам по себе является объектно-ориентированной программой, его могут расширять пользователи. Ну, может быть. А может быть, вы добьётесь даже большего, предлагая подконцепции объектно-ориентированного программирования по отдельности. Перегрузка, например, изначально не связана с классами. Посмотрим.
Объектно-ориентированные абстракции аккуратно ложатся на предметные области определённых видов программ — таких как симуляции и CAD-системы.
Лично мне объектно-ориентированные абстракции никогда не были нужны. У Common Lisp есть невероятно мощная объектная система, и я ни разу ею не воспользовался. Я делал множество вещей (например, создавал хеш-таблицы, заполненные замыканиями), для которых в более слабых языках потребовались бы объектно-ориентированные приёмы, но мне ни разу не пришлось применить CLOS.
Может быть, я просто туп или работал лишь над неким ограниченным подмножеством приложений. Есть опасность проектировать язык, исходя из собственного опыта программирования. Но ещё опаснее, как мне кажется, включать в него то, что вам никогда не было нужно, только потому, что это считается хорошей идеей.