Why Arc Isn't Especially Object-Oriented

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

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

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

• 1. Объектно-ориентированное программирование интересно, если у вас есть статически типизированный язык без лексических замыканий или макросов. В какой-то степени оно предлагает способ обойти эти ограничения. (См. Десятое правило Гринспуна.)
• 2. Объектно-ориентированное программирование популярно в крупных компаниях, потому что оно подходит для того, как они пишут программное обеспечение. В крупных компаниях программное обеспечение, как правило, пишется большими (и часто меняющимися) командами посредственных программистов. Объектно-ориентированное программирование налагает на этих программистов дисциплину, которая не позволяет ни одному из них нанести слишком большой ущерб. Платой за это является то, что получаемый в результате код раздувается протоколами и изобилует дублированием. Это не слишком высокая цена для крупных компаний, потому что их программное обеспечение, вероятно, все равно будет раздутым и полным дублирования.
• 3. Объектно-ориентированное программирование генерирует много того, что выглядит как работа. Еще во времена фанфолдинга существовал тип программистов, которые размещали на странице всего пять или десять строк кода, предваряя их двадцатью строками искусно оформленных комментариев. Объектно-ориентированное программирование - это как наркотик для таких людей: оно позволяет включать все эти строительные леса прямо в исходный код. То, с чем хакер Lisp мог бы справиться, вставив символ в список, превращается в целый файл классов и методов. Так что это хороший инструмент, если вы хотите убедить себя или кого-то другого, что вы проделываете большую работу.
• 4. Если язык сам по себе является объектно-ориентированной программой, он может быть расширен пользователями. Ну, может быть. А может быть, можно сделать еще лучше, предлагая подконцепции объектно-ориентированного программирования а-ля карт. Перегрузка, например, не привязана по своей сути к классам. Посмотрим.
• 5. Объектно-ориентированные абстракции четко отображаются на области некоторых специфических видов программ, таких как симуляторы и системы автоматизированного проектирования.

Лично мне никогда не требовались объектно-ориентированные абстракции. В Common Lisp есть чрезвычайно мощная объектная система, но я ни разу не использовал ее. Я делал много вещей (например, составлял хэш-таблицы, полные закрытий), для которых в более слабых языках потребовались бы объектно-ориентированные методы, но мне никогда не приходилось использовать CLOS.

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