Объектная парадигма
провалилась
оригинальный текст
- Ричард П. Гэбриэл
перевод
- Александр Майборода
Что это такое вообще — провал парадигмы
программирования? Парадигма терпит неудачу, когда содержащийся в ней посыл
утрачивает адекватность, или когда приверженцы парадигмы продолжают держаться
её вопреки здравому смыслу. Причиной утраты адекватности являются сильно
изменившиеся требования, предъявляемые к программному обеспечению в XXI веке, и
так называемые усовершенствования в ОО, перечеркнувшие его первоначальные
преимущества. Одержимость ООП переросла в продвижение частного решения в
качестве панацеи от всех проблем, связанных с программным обеспечением, превратившись
в идеологическое оружие, целью которого была промывка мозгов людям на улицах.
Утверждение «всё суть объекты» подразумевает универсальность ОО, а утверждение
«объекты моделируют реальный мир» говорит о привилегированном положении ОО.
Весьма заманчивое приглашение к единообразной точке зрения, приводящее к
замораживанию исследований и разработок альтернативных парадигм.
Когда-нибудь все программное обеспечение,
которые мы уже написали, будет иметь нулевую ценность. Мы пережили три
компьютерные эры: первая — кодирование в машинных кодах; вторая — ассемблеры,
интерпретирующие программы и ранние компиляторы; третья — эра императивного,
процедурного и функционального программирования, языков, ориентированных на
компиляторы. И вот, наступила четвёртая эра — объектно-ориентированного
программирования. Все четыре эры были ориентированы на программы, работающие на
одном компьютере. Хотя такие системы и сейчас представляют ценность, всё
возрастающая сложность систем приведёт к тому, что они будут состоять из сотен
тысяч или даже из миллионов различных компонент, приложений, служб, сенсоров и
приводов, работающих на различном оборудовании, написанных разными
производителями, так что не было бы ошибкой сказать — никто не знает, как это
всё работает. В старом мире мы фокусировали своё внимание на эффективности,
ограничении используемых ресурсов, производительности, монолитных программах,
отдельных системах, программах «одного автора» и математических моделях. В
новом мире на первый план выходят устойчивость, гибкость, адаптируемость,
распределённые системы, программы коллективных разработчиков и биологические
(взятые из жизни) метафоры в вычислительной технике.
Конечно, ОО-подход представляет собой
мощный инструмент, используя который, можно понять и обустроить системы в новом
мире, но он не может быть единственным инструментом. В будущих системах
ненадёжность (многих компонентов в целом) станет обычной, сложность выйдет за
пределы поля зрения, и строить системы на тщательно «вылизанном» коде станет
нереально. Это похоже на город: кирпичи важны для постройки зданий, но вся
разношёрстная гамма применяемых строительных материалов и компонент, и людей,
которые ими занимаются — разных культур, мировоззрений, возможностей и
талантов, приводит нас к мысли, что тип мышления одними только «кирпичами» не
будет работать в масштабах города. Кирпичи слишком ограничены, и
обстоятельства, в которых они могут применяться, тоже слишком ограничены, чтобы
использоваться в качестве модели для построение чего-то такого же разнообразного
и непредсказуемого, как город. Более того, город сам по себе тоже не является
конечной целью, поскольку он, в идеальном случае, суть «гуманитарное
образование для активности человека», понимание этого требует введения
дополнительного уровня сложностей и связей. Применяя эту метафору для разговора
о компьютерных системах будущего, будет справедливо заметить, что ООП сегодня
находится на «уровне кирпичей».
Современные тенденции в ИТ принуждают к
единообразному подходу, в рамках которого предполагается, что одна парадигма
устроит всех во всех ситуациях. Но, даже стараясь изо всех сил, приверженцы ОО
не могут предоставить убедительное итоговое решение, подходящее для всех без
исключения. У парадигмы ОО на самом деле нет привилегированной позиции. Поэтому
разработчики Java, к примеру, вместо того, чтобы использовать уже существующие
компоненты, решают включить в своё решение всё, что «может понадобиться», чтобы
весь компьютерный мир оказался охваченным Java.
Объекты, введённые дизайнерами таких
языков, как Smalltalk и Actors — задолго до C++ и Java — были созданы для
моделирования сложных, динамичных миров. Среда программирования в Smalltalk
была создана с использованием его же самого, и является расширяемой для
программистов-разработчиков. Поскольку философия динамических изменений была
частью «мировоззрения» языков, созданных после Simula, языки и среды того
времени были весьма динамичными.
Примечание переводчика: для тех кто не
знаком со Smalltalk, будет интересно узнать, что при разработке программ в его
среде, нет понятия этапов «дизайн-компиляция-исполнение» — изначально
задуманный как интерпретирующий язык, со временем переросший в компилирующий во
время исполнения (задолго до Java!), в конце концов стал «компилирующий и
сохраняющий результаты компиляции до изменения программного кода», с
оптимизацией. Трудности оптимизации в этом языке связаны именно с его
динамичностью, объекты Smalltalk имеют ограниченный набор методов (в привычном
понимании адептов С++), и всё что они «умеют» — посылать сообщения друг другу,
соответственно программирование в Smalltalk сводится к «обучению» объектов
реагировать на соответствующие сообщения. Причём новая реакция на новое
сообщение может быть добавлена «на лету» во время исполнения программы (читай
«добавление к объекту нового метода»). Однако были достигнуты приемлемые
результаты оптимизации. При выпуске программы «в мир» из неё просто исключался
за ненужностью модуль среды Smalltalk, поскольку программа отлажена и работает.
Но с приходом C++ и Java, динамичное
мышление, воспитанное в духе ранних объектно-ориентированных языков, было
практически полностью подавлено теологией статичного мышления, взятого из
математического наследия, и взглядами на вычисления, восходящими к Чарльзу
Бэббиджу, с мировоззрением, ориентированным на всеведение и всемогущество.
В результате мы пришли к тому, что
объектно-ориентированные языки поддались влиянию статично мыслящих
разработчиков, которые поставили тщательное планирование выше приспособляемости
программ во время исполнения, ранние решения выше поздних, и «мудрость»
компилятора выше умения обработки ошибок и восстановления.
Вместо статичных типов, точных
интерфейсов и математических обоснований, появилась острая необходимость в
самоорганизующихся механизмах, способных к самопроверке и различной реакции на
ошибки, в управляемых системах, общая сложность которых будет лежать за
пределами понимания одной личности.
Кто-нибудь может подумать, что подобный
постмодернистский шаг приведет к положительным последствиям, но, в отличие от
Perl, подобная комбинация привела не к сложению, а к вычитанию — как будто бы
ОО могло стать лучше при вырезании из него самой сути. Это могло бы сработать в
книжных примерах, но идея программирования — не учить, а строить.
Частный коммерческий успех объектов, и
наш бурно развивающийся в последнее десятилетие роман с большим бизнесом,
вылились в остановку изучения и разработки альтернативных языковых подходов и
парадигм в компьютерной науке. Научные и промышленные сообщества отступили от
исследований в сфере языков, пожиная лёгкие плоды с дерева ОО. Безумие большого
бизнеса конца прошлого века ослепило исследователей и привело к тому, что на их
взгляд, то, что существует в сфере ООП сегодня, настолько близко к идеалу, что
это бесспорно. И если когда-нибудь и было время, когда Куновская «нормальная
наука» доминировала в вычислительной технике, так именно в этот период (Томас
Кун в своей книге «Структура научных революций» показал, что принятие единой
парадигмы, в конце концов, обязательно приведёт к новой революции).
Я на собственном опыте перенёс это. До
того, как я ушел изучать поэзию в 1995 году, моя карьера исследователя
вращалась вокруг языка программирования LISP. Когда я вернулся в 1998, я
обнаружил, что моя область исследований оказалась уничтоженной. Я был вынужден
искать новые способы зарабатывания на жизнь в рамках новой экологии
компьютерного мира, созданного языком Java, который деловито перестраивал мир
программирования по своему образу и подобию.
Smalltalk, Lisp, Haskell, ML и другие
языки зачахли, в то время когда C++, Java и ее почти что клон C# стали
единственными языками, достойными внимания. Малые языки вроде Tcl, Perl и
Python ещё собирают своих приверженцев, но не демонстрируют значительного
прогресса как в языке, так и в системном дизайне.
Итак, мы пришли вот к чему:
1. сложившийся объектно-ориентированный поход неадекватен
требованиям вычислительных процессов будущего;
2. объектно-ориентированные языки потеряли простоту, а можно
сказать и чистоту, которая особенно их отличала и была источником их
выразительной силы и творческой мощи;
3. предполагалось, что такие мощные концепции, как
инкапсуляция, должны спасти людей от самих себя при разработке программ, но
инкапсуляция не срабатывает в ситуациях, где необходимо использовать глобальные
свойства, или когда необходимо развитие программы или ее коренная перестройка.
Концепция открытого исходного кода лучше справляется с подобной ситуацией.
Похоже, что только модульность — разбиение на составные части так, чтобы люди
могли их понять — вот что действительно важно в инкапсулировании;
4. объекты обещали повторное использование, однако мы не
наблюдаем больших достижений в этой области;
5. несмотря на ясное понимание пионерами ОО природы разработки
программ, нынешнее поколение их преемников более озабочено философией
тщательного планирования, монументального дизайна, идеей охватить всё,
«всеведением», взятым из теологии Бэббиджа;
6. эйфория, порождённая объектами в ранних 1990, вела к
ожиданию чудес, которые могли бы стать возможными при незагрязнении статичным
мышлением, когда же нынешние разработчики ПО оказываются не в состоянии
добиться желаемого, рушатся и возмутительные планы этих бизнесов, результатом
чего является нынешняя рецессия;
7. объекты требуют программирования методом создания
общающихся сущностей, это означает, что программирование осуществляется путем
построения структур, а не языковых выражений и описаний с помощью форм, что
часто приводит к несоответствию языка предметной области;
8. объектное проектирование похоже на написание рассказа,
в котором создаётся мир, где объекты разговаривают и взаимодействуют между
собой. Это приводит людей к выводу о легкости обучения
объектно-ориентированному программированию, хотя фактически это стало трудно,
как никогда.
9. те, кто пришли в восторг от ООП, заслонили дорогу и не
сходят с неё, не давая другого выбора — не по злому умыслу, а от богатства — и
вот, ресурсы, которые могли быть использованы для альтернативных исследований,
иссякают. Но однажды их богатство исчезнет, поскольку будет растрачено на
сталкивание с дороги других.
В конце концов, никто не агитирует менять
то, как мы работаем с объектами и объектно-ориентированными языками. Нет,
просто необходимо разнообразие, необходимо работать над новыми парадигмами,
чтобы «дать расцветать тысячам цветов». Самовосстанавливающиеся, распределённые
и сложные системы, самоорганизующиеся, адаптирующиеся, растущие по крупицам как
живые организмы, использующие статистическое поведение, эволюционирующие,
использующие избыточность ради безаварийности — систем, в основе которых могут
быть ещё сотни различных перспективных идей и подходов, о которых мы еще и не
думали — всё должно быть позволено и поддержано для движения вперёд.
Сейчас самое время для определения новой
и смены старой парадигмы. Часто новое вообще не выглядит научно, или
рационально, статьи и разговоры, объясняющие новые идеи могут звучать как
пропаганда, как фантастика, или даже как поэзия; действительность же играет
большую роль, чем теоремы или точные результаты. Можно сказать, что это не
будет наукой в нашем привычном понимании.
В свете всего вышесказанного, можно с
уверенностью заявить, что объектная парадигма обманула наши ожидания.
С.П.
Капица. Кому должна принадлежать
интеллектуальная собственность?
Программа - генератор
самоподобных случайных процессов