Предлагаются альтернативные парадигмы программирования

Ну, вот... Давал же себе зарок не браться за новые переводы. Однако попалось под руку свежее интервью Страуструпа, взятое у него 21.02.2001 Денни Калевом (Danny Kalev) под исходным названием: "Будущее за мультипарадигменным программированием", и не удержался. Этому способствовали несколько факторов.

Во-первых, то, что говорит Страуструп, во многом совпадает с моими собственными мыслями. Более половины следующих заметок по парадигмам программирования уже написано. Вместо того, чтобы с умным видом ссылаться на эту публикацию, я решил ее выложить в полном объеме и, тем самым, показать, что я не одинок на пути смешанного использования нескольких парадигм. Кстати, термин "мультипарадигменное программирование" (multiparadigm programming) мне самому тоже не нравится, так как ассоциируется с такими словами как "мультишизофреническое" и "мультимаразматическое". Но я решил не менять исходного названия. Сайт-то ведь - любительский.

Во-вторых, недавно вышел перевод книги Страуструпа "Дизайн и эволюция C++", которую я сейчас читаю в фоновом режиме. Поэтому мне было интересно сравнить взгляды Страуструпа на язык, опубликованные в 1996 году с его текущими воззрениями. Тем более, что его с первой книгой по C++ я познакомился еще в 1991 году. Сам лично распечатывал на игольчатом принтере пару сотен страниц. При этом первые сто страниц, напечатанные старой лентой, были очень плохого качества и читались с большим трудом. Так что, можно сказать, что освоение ООП проходила с огромными сложностями:).

В третьих, наверное, сработал рефлекс препода. Привычка всех поучать, выработанная с годами. Особенно, когда под рукой оказывается пример, удобный для манипуляции в нужном русле:).

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

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

Другим фактором, сдерживавшим ускоренное распространение ОО парадигмы, на мой взгляд явлалась слабая инфраструктура. Сколько времени проходит с момента написания статьи до ее публикации, даже в местном сборнике? Иногда, несколько лет. А сколько человек прочтет эту статью? В местном сборнике - не больше десятка. А сейчас!? Даже мой захолустный и провинциальный сайт ежедневно посещают около ста человек. Выскажу крамольную мысль: если появится новая парадигма, эквивалентная по эффективности объектно-ориентированной, то она наберет популярность в два, а то и в четыре раза быстрее, чем ООП.

Мне понравилось, что Страуструп повторил, хоть и забитую, мысль о том, что любую проблему, особенно в программировании, можно решить различными методами. Более того, программирование изначально провоцирует разнообразие методов решения из-за гибкости строительного материала: информации. Поэтому я не спорю, что в будущем действительно будут одновременно сосуществовать множество парадигм. И конечно же, мне не понравилось то, что функциональному программированию отведена роль идеологического придатка STL. Но каждый судит о других со своей колокольни. По крайней мере я рад, что C++ в основном останется таким, каков есть, а не будет обрастать новыми функциональными возможностями. Зачем наворачивать еще один язык, если вместо него, в соответствующих приложениях, можно использовать другой.

Заинтересовал меня еще и некоторый исторический срез с упомянутых работ Страуструпа. Если в первом издании книги по C++ была ориентация на внедрение новых идей, а процедурность языка рассматривалась как промежуточное звено перед переходом к ООП, то уже в "Дизайне и эволюции" отношение к различным парадигмам было более сбалансированным. При этом стиль изложения от первооткрывательского сменился на слегка вальяжный (но не высокомерный). Это был период наивысшей популярности языка, который ни от кого не надо было защищать, так как он, по заложенным идеям опередил всех своих конкурентов. В интервью же прсматривается неудовлетворенность текущим положением. Язык зажимается производителями, нет четкого финансирования, слабо поставлена информационная поддержка и т.д. Как результат надо открывать коды библиотек. Думаю, что дело не в этом. Скорее всего, C++ остался за чертой массовой культуры в прогрммировании, акцентированной на упрощенные методы разработки. Он интересен в основном системным программистам и корпоративным разработчикам. То есть тем, кто уделяет больше внимания системной алгоритмизации и внутренней эффективности приложений. Для остальных же - это излишне расточительный инструмент, требующий долгого и кропотливого изучения. Возможно и то, что ряд выводов, связанных с необходимостью открывать код, определены источником публикации: сайтом для Линуксоидов.

В заключении хотелось бы упомянуть источник ссылки на это интервью, послуживший моему внеплановому вдохновению. Это первый номер электронного компьютерного журнала D.O.M. Приятно, что в Красноярске появился еще один генератор компьютерных публикаций, многие авторы которого известны мне не понаслышке. Территориальная близость позволяет, в случае чего, перейти к непосредственному выяснению отношений.

А. И. Легалов (18.03.2001)