В статье представлено моё видение на эволюцию функциональной парадигмы программирования и процессы популяризации функциональных языков программирования на примере языка Haskell. Изучаются причины общей низкой популярности как функционального программирования, так и одного из его «флагманов». Приводятся факторы, которые не позволят языку программирования Haskell стать таким же широко используемым языком, как Java, C++, PHP и др.
Когда в конце 2006 года я готовил последние материалы для публикации своей первой книги по функциональному программированию и языку Haskell [1], один из коллег автора, приглашённый для вычитки и рецензирования, попытался сделать пророчество относительно «золотого» будущего функциональной парадигмы в деле разработки программного обеспечения промышленных информационных и автоматизированных систем (в качестве лирического отступления можно привести несколько смягчённые слова пророчества: «Скоро настанут времена, когда программисты на языке Haskell будут жить в дворцах с золотыми унитазами, а программисты на языках Java, C++ и им подобным будут работать за еду»). С тех пор прошло достаточно времени, чтобы успеть построить если и не дворец, то хотя бы домик, однако в деле распространения и повышения популярности языка Haskell и функционального программирования в целом каких-либо значимых результатов практически нет.
Имеет смысл разобраться с этой ситуацией и рассмотреть основные причины и факторы, не дающие языку программирования Haskell стать достаточно популярным для того, чтобы работодатели отрывали знатоков этого языка с руками, а функциональная парадигма программирования стала «мейнстримом».
Ещё в 1998 году Филип Уодлер написал неплохой обзор «Почему никто не использует функциональные языки программирования» [2]. В этой статье автор резонно указал, что такие факторы как эффективность, быстродействие, наличие компиляторов под основные промышленные платформы и др. — это не причины низкой популярности функциональной парадигмы. Более того, уже сегодня практически сходит на нет воздействие таких факторов, как совместимость, наличие достаточного количества библиотек, мобильность и интероперабельность, доступность утилит и инструментальных средств. Сообществом любителей функциональной парадигмы все эти аспекты использования языка Haskell развиваются в достаточной мере.
Тем не менее, отмеченные в статье Ф. Уодлера такие факторы непопулярности, как доступность технической поддержки, обучаемость и, как ни странно, популярность являются на текущий момент наиболее существенными причинами, по которым язык Haskell остаётся инструментом энтузиастов и научных лабораторий, но не выходит на уровень языка, используемого в промышленности при разработке программного обеспечения информационных и автоматизированных систем. Эти три фактора стоит рассмотреть более подробно:
Доступность технической поддержки. Одним из факторов, принимаемым во внимание руководителем проекта при рассмотрении готовых к использованию инструментальных программных средств и библиотек сторонних производителей является доступность технической поддержки и ответственность разработчика за своё изделие. Особенно это касается разработки автоматизированных систем управления для непрерывных технологических процессов на опасных производствах. Если для информационных систем управления каким-нибудь документооборотом нет нужды следовать стандартам безопасности (не информационной, а самой непосредственной, физической безопасности), то для пожароопасных и взрывоопасных производств техника безопасности является одним из главных факторов даже при разработке автоматизированных систем.
В случае разработки автоматизированных систем классов АСУ П (автоматизированная система управления предприятием, в англоязычной терминологии — ERP) и СППР (система поддержки принятия решения, в англоязычной терминологии — BI) одним из главных является вопрос информационной безопасности. При использовании сторонних программных средств руководитель проекта всегда будет думать о том, кто даст гарантии и ответит за проблемы, возникшие по вине разработчиков сторонних продуктов. Даже идеология открытых исходных кодов здесь не помогает — открытая библиотека доступна для изучения, но ответственных за неё всё же нет. И получается, что ответственность за чужой по сути код возьмёт на себя проектная команда. И, соответственно, для минимизации рисков проектная команда должна будет очень скрупулёзно изучить и протестировать эти самые открытые исходные коды, что по времени вполне сравнимо с разработкой «с нуля».
Таким образом, несмотря на наличие для языка Haskell большого количества готовых открытых библиотек, которыми наполнен архив Hackage, у руководителей проектных команд, занимающихся разработкой промышленных программно-аппаратных систем, возникают очень большие сомнения в возможности их использования в своих проектах.
Обучаемость. Другой важной причиной, почему руководители проектов с опаской и недоверием относятся к «эзотерическим» языкам программирования и нестандартным (не «мейнстримным») парадигмам, является то, что для получения серьёзного специалиста в таких языках и парадигмах необходимо вложить в него несравненно больше знаний, чем при использовании обыденных инструментов вроде объектно-ориентированного программирования. Не «мейнстримные» парадигмы программирования требуют от своих адептов при овладении намного больше усердия и рвения, чем те, которые «используются всеми». Это — странная ситуация, поскольку невозможно доподлинно сказать, что естественней для человеческой психики — выражать решение задачи через последовательность действий (императивная, процедурная парадигма), или через декомпозицию задачи на подзадачи, в том числе и рекурсивно (функциональная парадигма). Что естественней — выражение сущностей предметного мира через объекты и их свойства (объектно-ориентированная парадигма) или через функциональность, которую можно применить к имеющимся сущностям (функциональная парадигма и теоретико-категориальный подход)? Эта тема ещё ждёт своего исследователя (см. также мысли в [3]).
В итоге я вспоминаю, что после выхода очередного номера научно-практического журнала «Практика Функционального Программирования» в сети Интернет в блогах читателей появляются слова вроде: «Читаю журнал. Хочется бросить всё и поступить в хороший технический ВУЗ» [4]. Естественно, что подобное реноме сложных для постижения языков программирования не усиливает их позиций в глазах руководства, принимающего решения о выборе средств разработки.
Кроме того в этом деле имеется ещё один аспект, связанный с межличностными отношениями в проектной команде. Руководитель проекта, набирающий персонал под своё руководство, ещё сто раз подумает над тем, кого выбрать — «ботаника», закончившего ВМК МГУ с красным дипломом и имеющего на очках линзы толщиной 5 см (это стереотипное описание — просто фигура речи; никого конкретного я не имею в виду; более того, я против такой стереотипизации образа людей, работающих с функциональными языками, поскольку опыт показывает, что всё далеко не так), но зато владеющего сотнями различных парадигм и свободно общающегося на сотнях же «эзотерических» языках программирования, либо вполне обычного человека, умеющего не только закодировать какой-либо алгоритм, но и поговорить на общие темы, сыграть в кегельбан после работы или даже съездить на шашлык в грядущие выходные.
Проектные команды, состоящие из социопатов, вряд ли добьются успеха в современном окружении. Будет намного проще и эффективнее инвестировать время в социально адаптированных сотрудников, для которых можно провести пару или тройку занятий по информатике и математике (если необходимо). Например, специалисту, заявляющему на собеседовании, что «настоящему программисту нет необходимости владеть математическим аппаратом» (из моего личного опыта), можно для систематизации и структуризации знаний преподать теоретические основы представления и кодирования информации. Обучать сотрудников хотя бы основам той же теории категорий для получения эфемерных эффектов при работе — бесполезная и нецелесообразная трата проектного времени, поскольку усилия, затраченные на разъяснения, не окупятся ни при каких обстоятельствах.
Популярность. Доступность парадигмы и зыка программирования для обучения прямым образом сказывается на популярности функциональной парадигмы. Получается, что скрупулёзное изучение функциональных языков программирования (или хотя бы только одного) продолжают после поверхностных лекций в институте лишь самые фанатичные студенты, которых настолько «зацепили» свойства функциональных языков, что остановиться они уже не смогли. Большинство же изучавших функциональное программирование в институтах благополучно забывают про него, как про «страшный сон» после сдачи зачёта или экзамена.
Когда приходит время запускать проект по разработке какого-либо программного средства, то руководитель проекта просто не сможет найти достаточного количества специалистов, чтобы иметь возможность экспериментировать с функциональными языками программирования. Более того, с этой же ситуацией сталкиваются и научные лаборатории, где функциональная парадигма используется намного чаще, чем в промышленности. В лабораториях приходится задействовать студентов с лабораторными работами и аспирантов, которым иной раз просто некуда деваться. В итоге каждая научная лаборатория выращивает кадры для себя чуть ли не с нуля, но промышленные проекты подобной возможностью похвастаться не могут.
Эти факторы рассмотрены с точки зрения руководителя процесса разработки программного обеспечения (руководителя проекта). Его точка зрения довольно важна, поскольку решение относительно используемых для разработки инструментальных средств если и не принимается им напрямую, то, по крайней мере, принимается на основе его представления высшему руководству. Лицо, принимающее решение, будет рассматривать все значимые факторы и риски, способные повлиять на успех проекта, в том числе и вышеперечисленные факторы.
Рассмотренная ситуация приводит к тому, что традиционные императивные и объектно-ориентированные языки программирования перевешивают в споре парадигм, поскольку при более или менее равных условиях по производительности, эффективности кода и т. д. существуют дополнительные факторы, которые не позволяют руководителю проекта принять в качестве рабочего немейнстримный инструментарий. Дело в том, что имеются серьёзные риски получить неподдерживаемые исходные коды на «эзотерическом» языке программирования, адептов которого на рынке труда можно пересчитать по пальцам рук и ног (соответственно, их можно назвать локальными «звёздочками» с вытекающими из этого последствиями — повышенные требования к оплате за услуги по обучению инженерного персонала и ведению проектов, что в свою очередь влечёт риски по срыву сроков и бюджета проекта). На другой чаше весов лежат эфемерная возможность кардинального уменьшения сроков разработки и практическое отсутствие необходимости в функциональном тестировании исходных кодов (при этом другие виды тестирования, в том числе и комплексное тестирование готовой автоматизированной системы управления, всё так же будут необходимы). Само собой разумеется, что руководитель проекта не будет даже смотреть в сторону функциональных языков программирования, какими бы прекрасными они ни были, даже если он сам является энтузиастом и апологетом того же языка Haskell.
Единственная возможность для функционального языка программирования быть использованным в промышленной разработке — если в одном проекте по разработке программного обеспечения сойдутся как руководитель-энтузиаст, так и длительные сроки разработки (проект должен быть «длинным»). В этом случае есть шанс убедить лиц, принимающих решения, попробовать поэкспериментировать, заложив достаточные резервы времени на возможность провала эксперимента.
С другой стороны всё вышеописанное приводит к появлению эффекта, который вслед за Б.~Гейтсом можно назвать «петлёй положительной обратной связи» [5]. Отсутствие интереса работодателей к функциональной парадигме программирования приводит к нежеланию молодых специалистов инженерных специальностей заниматься повышением своей квалификации в этом направлении. Это приводит к отсутствию специалистов в области функциональных языков программирования, что в свою очередь усиливает влияние на руководителей проектов в их нежелании применять «эзотерические» парадигмы программирования.
Этот эффект можно пояснить простым примером. На ХедХантере, одном из ведущих web-сайтов по поиску работы, среди всех опубликованных вакансий во всех областях деятельности за последний месяц словосочетание «функциональное программирование» (в любой форме, даже в виде сокращения) встречается только 2 раза, в то же время словосочетание «объектно-ориентированное программирование» встречается порядка 550 раз. Что касается упоминания в описаниях вакансий конкретных языков программирования, то языки Haskell и Erlang упоминаются по 6 раз, язык Lisp упоминается 5 раз, язык OCaml упоминается 3 раза, причём можно считать, что всего имеется 6 вакансий, которые интересны программистам на функциональных языках программирования, поскольку все перечисленные языки встречаются в описании одних и тех же вакансий, причём в контексте «желательно знание интересных языков программирования, таких как...». С другой стороны, такие языки как Java, C++ и C# встречаются в описаниях вакансий от 500 до 1000 раз.
Такая ситуация не может не влиять на выбор молодых специалистов. Естественно, что мало кто захочет тратить своё время на изучение необычных языков программирования, пусть даже превосходящих по красоте и продуктивности деятельности разработчика обычные «мейнстримные» языки, но не интересные работодателям.
В качестве дополнительного предположения из вышеизложенного можно отметить, что данная петля положительной обратной связи уже пагубно сказалась на многих аспектах использования функционального программирования в общем и языка Haskell в частности. Например, можно отметить, что по данным аналитического отчёта компании TIOBE Software [6] популярность функциональной парадигмы программирования находится где-то в районе 3 %, в то время как у объектно-ориентированной парадигмы популярность зашкаливает за 50 %. В первую двадцатку входит лишь один язык программирования, который с натяжкой можно назвать функциональным — Ruby. Все функциональные языки программирования крепко сидят в интервале от 21 (Lisp) до 50 (Haskell) места.
Данные этого отчёта коррелируют с текущим уровнем популярности языков программирования, которые используются в учебных и развлекательных целях. Если рассмотреть такие интернет-ресурсы, как «Проект Эйлер», то и на них уровень популярности функциональных языков программирования снижается (официально подтверждённых данных нет, данное утверждение основано на личном опыте автора). Если несколько лет назад язык Haskell находился в пятёрке используемых для решения задач языков программирования, то сегодня пользователи, решившие наибольшее количество задач, используют такие языки программирования как C++, Java, Python, C# и др.
Ситуация плачевна. Работа на ниве популяризации функциональной парадигмы программирования в общем и языка Haskell в частности видится безблагодатной. В будущем популярность языка Haskell будет только падать в относительном сравнении с объектно-ориентированными языками программирования. Скорее всего, такое положение вещей никогда не будет выправлено, и пророчество о «золотых унитазах», приведённое в начале статьи, так и останется голословным.
В связи с вышеописанным можно дать рекомендацию, которая, возможно, поможет как начинающим, так и умудрённым опытом разработчикам программного обеспечения. Учитывая данные уже упомянутого аналитического отчёта [6], имеет смысл развивать свои навыки в таком языке программирования, как PHP. Этот язык набирает мощнейшие обороты в практике разработки промышленных программных средств и создания автоматизированных и информационных систем. Учитывая, что стоящие на первых двух местах языки программирования Java и C/C++ являются более или менее общеизвестными, то как для повышения своего уровня привлекательности для потенциальных работодателей, так и для собственного развития имеет смысл изучать именно этот язык.
Ну, а функциональную парадигму программирования и язык Haskell можно оставить фанатикам.
Источники
- Душкин Р. В. Функциональное программирование на языке Haskell. — М.: ДМК-Пресс, 2007. — ISBN 5-94074-335-8.
- Wadler P. Why no one uses functional languages // ACM SIGPLAN Notices, August 1998. — Имеется перевод Дехтяренко И. А. на русский язык: «Почему никто не использует функциональные языки».
- Душкин Р. В. Функциональный подход в программировании // Практика функционального программирования, № 1(1), 2009. — Стр. 47-55. — ISSN 2075-8456.
- Пользователь yelbota. Запись в блоге: juick.com/yelbota/570694.
- Гейтс Б. Бизнес со скоростью мысли. — М.: Эксмо-Пресс, 2005. — ISBN 5-04-006117-X.
- TIOBE Software March Headline: Objective-C's popularity still rising, Go falling behind // Programming Community Index, March 2010. — www.tiobe.com/index.php/content/paperinfo/tpci/.
Автор: Darkus
