Почему haskell не популярен

Скажите, если Haskell так хорош, то почему он так не популярен?

xpl скажет что Эрланг всё равно круче 🙂
а вообще вопрос риторический 🙂 Технический/теоретический экселенс по сути локальный экстремум, что собсно не так уж сильно влияет на результаты :\ выражаясь на русском: хоть на чем ты пиши — всё равно придеться думать, всё равно будут ошибки 🙁 Ну и конечно — никто не хочет напрягаться если и так платят 🙂

• Sbtrn. Devil
• Постоялец

#4
11:32, 5 ноя 2006

Как и другие непопулярные языки — в основном, потому, что нераскручен, вот и всё.
Ну и ещё некоторые малозначительные нюансы там есть, но они уже глубоко второстепенные. 🙂

#5
17:17, 5 ноя 2006

Он непопулярен потому что порог вхождения очень высокий. Любой школьник может быстро начать писать на C++, а для Haskell надо очень много чего лишнего знать — мат. логику, теорию множеств, теорию категорий, теорию графов, и еще всякую гадость и чушь. Пишите на C++ или Delphi, там думать лишнего не надо и цепочку из монад тянуть в каждую функцию где хочешь буквочку-другую на экран вывести не придётся.

#6
18:26, 5 ноя 2006

KewlHuckeer

Т.е. перспектива использовать его в «промышленной разработке» стремится к нулю?
И на нем больше чем писать «для души» не получится?
Т.к. ни кому не нужны незаменимые участники проекта, это раз.
В одиночку я все равно много не напишу, а где я еще хаскельшиков найду? – это два.

Хм… замкнутый круг вырисовывается. 🙁

#7
18:30, 5 ноя 2006

9 Lives, Haskell используют в промышленной разработке. Например, в задачах, связанных с разработкой железа (формальная верификация VHDL-кода и другие подобные гадости). Haskell используют для быстрого прототипирования языков (Perl 6 пишут на Haskell). То есть, им пользуются там, где участники проекта просто по определению незаменимы — когда требуется и без того огромный уровень компетенции инженеров, такой, что Haskell для них — раз плюнуть. А там, где проект можно реализовать силами полуграмотных ПТУшников, Haskell конечно же на фиг не нужен.

#8
19:42, 5 ноя 2006

KewlHuckeer
Спасибо, все стало на свои места.

Почему язык Haskell так непопулярен

В статье представлено моё видение на эволюцию функциональной парадигмы программирования и процессы популяризации функциональных языков программирования на примере языка 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 можно оставить фанатикам.

Источники

1. Душкин Р. В.Функциональное программирование на языке Haskell. — М.: ДМК-Пресс, 2007. — ISBN 5-94074-335-8.
2. Wadler P.Why no one uses functional languages // ACM SIGPLAN Notices, August 1998. — Имеется перевод Дехтяренко И. А. на русский язык: «Почему никто не использует функциональные языки».
3. Душкин Р. В.Функциональный подход в программировании // Практика функционального программирования, № 1(1), 2009. — Стр. 47-55. — ISSN 2075-8456.
4. Пользователь yelbota. Запись в блоге: juick.com/yelbota/570694.
5. Гейтс Б.Бизнес со скоростью мысли. — М.: Эксмо-Пресс, 2005. — ISBN 5-04-006117-X.
6. TIOBE SoftwareMarch Headline: Objective-C’s popularity still rising, Go falling behind // Programming Community Index, March 2010. — www.tiobe.com/index.php/content/paperinfo/tpci/.

Говорят, Haskell — язык для гениев и академиков. Правда?

Однажды я разговаривал с основателем израильского стартапа, который разрабатывал скоростную базу данных на GPU. В их стеке были Haskell и C++, и основатель жаловался, как тяжело найти людей в команду. В Москву он прилетал в том числе искать хороших программистов.

Я осторожно спросил, не лучше ли было использовать что-то более распространенное и новое. И хоть ответ был вежливым и конструктивным, между строк мне показалось: «Пфф, даже не упоминай эти игрушечные япы».

Все, что я слышал про Хаскель со стороны с тех пор, сводилось к одному — «с ним шутки плохи». Чтобы узнать хаскелистов получше, я пришел с расспросами к ним в телеграм-чат. Было довольно страшно, и как оказалось, не зря.

О Хаскеле не стремятся говорить популярно, и на такие затеи, кажется, поглядывают с презрением. Уж если говорить — то с максимальной полнотой и объективностью. «Одно из характерных качеств Хаскеля как языка и сообщества в том, что они вместе не стремились стать популярными, дав простой ответ на популярные вопросы. Вместо этого выстраивали логичный principled путь решения реальных проблем, а не быстрого проникновения в сердце прохожего интересующегося» — написали мне там.

Тем не менее, несколько человек рассказали о своем опыте, и я собрал их мнения здесь.

Денис Мирзоев (nolane): В университете по предмету «Языки программирования» мне предложили пройти курс на Coursera по Хаскелю за один дополнительный балл из ста. Потом ещё был курс функционального программирования, на котором проходили Хаскель. Написал курсовую и выпускную работу бакалавра по GHC. Нашёл работу в качестве Хаскель-программиста.

Было тяжело, и тяжело до сих пор. Когда начинаешь изучать Хаскель, приходится постигать очень много новых концепций. Это сложная работа. Буквально учишься программировать заново.

Многим сейчас будет трудно вспомнить, как они начинали свой путь в программировании, как трудно было понять, что такое «указатель», что такое «функция», что такое «класс». Возможно поэтому изучение Хаскеля даётся так тяжело. С возрастом становится труднее усваивать новое.

Doctor_Ryner: Однажды на испытательном сроке я завалился на Redux, поэтому, смотря уроки от его создателя, решил поближе с этим всем познакомится. Сначала применял изученные практики в JavaScript, но потом узнал о Haskell, который считается истинным функциональным языком. Меня сразу привлекла его элегантность и куча новых неизвестных мне концепций.

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

Юрий Сыровецкий (cblp): Сложнее всего изучать Хаскель вторым, когда не прошёл синдром утёнка к первому языку.

Чем хорош и чем плох язык?

Doctor_Ryner: Язык очень краткий, элегантный и гибкий, не зря на нем половина библиотек — это EDSL (как минимум такое впечатление).

Юрий Сыровецкий (cblp): Высокая выразительность, легко переносить предметную область в код, оптимальное сочетание императивной и функциональной парадигм. Легко строить абстракции над данными и алгоритмами, что позволяет думать о задаче, не отвлекаясь на несвязанные мелочи.

Джон Доу: Строгая сильная (я бы сказал, фашистская) типизация.

Игорь Шевнин (interphx): Очень выразительная система типов. Не настолько мощная, как у Idris или Agda, но достигает той золотой середины, когда выразить можно почти всё, и при этом вывод типов работает нормально. Не надо везде помечать их вручную.

Но мощная система типов заставляет внимательнее относиться к передаваемым значениям. Куча определений типов может выглядеть как бойлерплейт. Каждая команда использует свой набор расширений или не использует их вообще. Код более «плотный» — одна строчка часто несёт больше информации, чем в других языках, поэтому неопытному разработчику сложнее его читать.

Doctor_Ryner: Изучая Haskell, ты скорее всего наткнешься на высказывание «if it compiles, it is probably correct». Тут нет null, сама функциональная парадигма очень строга и принуждает тебя следовать определенным правилам, которые в большинстве случаев ведут к лучшему дизайну.

Например, в языке нет переменных — только константы. Тебе не приходится следить за тем, что и где ты присваиваешь. Haskell поощряет использование чистых функций, что ведет к отсутствию побочных эффектов. Функциональный дизайн просто заставляет программу работать как одно целое, в противовес ООП, где в мир выброшена куча объектов и объекты пытаются общаться друг с другом путем побочных эффектов, превращая приложение в непредсказуемое месиво. На работе достаточно страдаем от такого с C# в Unity.

Денис Мирзоев: Встроенная ленивость повышает выразительность языка. Многие алгоритмы становятся проще. Она может увеличить производительность, если результаты промежуточных вычислений не будут использоваться. (К примеру `head. sort` работает за линейное время).

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

Doctor_Ryner: Он компилируемый, что сразу же дает огромный прирост в скорости.

Денис Мирзоев: По скорости сравним с Java, но не такой быстрый как C.

Игорь Шевнин: Из коробки есть поддержка расширений, которые позволяют допилить язык и систему типов. При этом есть много широко используемых расширений, которые знакомы сообществу, имеют приличные примеры и документацию и не являются нишевыми.

Doctor_Ryner: В стандартной библиотеке Prelude есть очень плохие функции наподобие read, head, readFile, которые могут выкинуть Exception и положить программу, вместо того, чтобы возвращать Maybe. Поэтому приходится использовать альтернативы или писать свои реализации.

Игорь Шевнин: Главная проблема — отсутствие стандартизации, вплоть до того, что многие заменяют стандартную библиотеку на одну из несовместимых между собой альтернатив. Есть разногласия в сообществе на тему того, какой должна быть стандартная библиотека, что должно входить в ядро языка, а что допиливаться расширениями, и по моим ощущениям это тормозит развитие языка.

Денис Мирзоев: Не хватает тулов: нет полноценной IDE, очень мало средств для замеров производительности, нет отладки «по шагам» — это вообще говоря фундаментальная проблема.

Для каких проектов Haskell подходит лучше всего?

Юрий Сыровецкий: Для сложных задач, связанных с безопасностью или деньгами, где высока цена ошибки.

Doctor_Ryner: Для всего, где нужно проводить вычисления, преобразование и анализ данных. Сильно удивлен, что Haskell менее популярен в Data Science, чем Python.

Игорь Шевнин: Я бы не рискнул использовать его для встраиваемых систем (производительность неплоха, но всё же есть значительный оверхэд по потреблению памяти из-за ленивых вычислений) и мелких скриптов (там эта строгость просто не нужна). Также надо понимать, что найти разработчиков в команду намного сложнее, чем для мейнстримных языков.

Джон Доу: Чтобы писать промышленный код, который будут читать другие — вам нужна будет целая команда хаскеллистов. Такую мало кому удалось собрать.

Игорь Шевнин: Но благодаря краткости и строгости Haskell подходит почти для любых задач.

Начинать изучать разработку с Haskell — хорошая идея?

Игорь Шевнин: Начинать — вряд ли, потому что подавляющее большинство кодовых баз, с которыми человеку придётся работать, написаны не на нём.

Джон Доу: Плохая, плохая идея! Языки не из семейства ML — а такие из промышленных вообще все — потом будут для вас шоком.

Денис Мирзоев: Обычно люди сначала изучают математику, потом переходят к программированию. Поэтому изучение языка, использующего математические концепции (алгебраические типы данных, чистые функции), должно быть проще императивных. То есть я считаю, что это хорошая идея.

Doctor_Ryner: Всех новичков, которых я обучаю, я обязательно знакомлю с Haskell. Люди, которые не изучали императивные стиль, гораздо проще ориентируются в функциональном коде и быстрее учатся, потом даже если работают с объектно-ориентированными языками, они привносят хорошие архитектурные решения и функциональные практики.

Юрий Сыровецкий: Начинать лучше сразу с нескольких принципиально разных языков, например, Си, Хаскель и Смолток, в любом порядке. Ни один язык в
отдельности не даст полного понимания.

Haskell — достаточно старый язык. Это хорошо или плохо?

Юрий Сыровецкий: Развивается язык очень активно, груз совместимости только ради совместимости не тянет.

Джон Доу: Стандарт принят в 1998-ом, но это не заметно: до сих пор новые версии компилятора, потенциально ломающие обратную совместимость, выходят примерно раз в полгода.

Денис Мирзоев: Haskell не старый, а проверенный временем. В язык никогда не попадут непродуманные изменения. Так что это скорее хорошо.

Про Haskell говорят, что это один самых сложных языков. Это так?

Doctor_Ryner: Как сам язык — нет. Сложны скорее абстракции, которые в нем используются. Человек, который никогда не видел кода на Haskell, может просто сойти с ума от потока новой информации и разных непривычных конструкций.

Масло в огонь подливает то, что язык накладывает кучу «ограничений», не позволяет или сильно затрудняет кучу вещей, которые не вписываются в функциональную концепцию.

Джон Доу: Чтобы первый элементарный проект хотя бы просто скомпилировался, ушло почти два месяца курения учебников, мануалов и туториалов по вечерам. Правда скомпилировавшись, проект сразу заработал и фигачил под полной нагрузкой (6k rps с пиками до 15) полгода, без изменений вообще.

Денис Мирзоев: Готов поспорить, что если школьник начнёт изучать программирование с Хаскеля и продвинется достаточно далеко, то императивное программирование ему покажется более сложным и менее интуитивным.

Игорь Шевнин: Сложность относительна. Из мейнстримных языков я всё ещё считаю C++ самым сложным. Языки для доказательства теорем (Agda, Coq) будут посложнее Хаскелля в концептуальном смысле. Haskell — несложный язык, но его паттерны и библиотеки — стандартные и сторонние — выучить удастся далеко не сразу.

Всегда ли его сложность оправдана?

Игорь Шевнин: Паттерны и высокий уровень абстракции оправданы, так как делают код надёжнее и короче. Но думаю, что операторы, имена функций и многие другие вещи могли бы быть понятнее.

Doctor_Ryner: Зачастую сложные конструкции Haskell позволяют создавать очень короткие решения, которые еще и оказываются очень гибкими и модульными.

Юрий Сыровецкий: Разве что управление эффектами бывает громоздко, хотя почти
всегда это лучше, чем отсутствие управления. Но над его упрощением
ведутся работы.

Джон Доу: Язык для привыкших к обычным python/php/whatever вообще производит впечатление ортогонального к реальности. Для людей, которые изначально не интересовались теорией категорий, добиться результатов с абсолютного нуля — очень тяжело.

Но когда понимаешь язык — получаешь новый способ думать о решаемой проблеме.

Haskell видится языком как будто для математиков, а не для разработчиков. Как думаете, он не распространен широко из-за этого?

Денис Мирзоев: Это демонстрация принципа, которому следуют главные разработчики Хаскеля — «avoid success at all costs». Смысл, конечно, не в том, что нужно избегать успеха, а в том, что нужно избегать успеха, цена которого слишком высока.

Можно было сделать Хаскель популярным. Есть, к примеру, поддержка этого языка со стороны Microsoft. Можно было сделать язык более императивным, принимать какие-то быстрые и непродуманные решения, чтобы завоевать популярность. Можно было использовать много грязных приёмов, но благодаря такой правильной позиции главных разработчиков ничего подобного не было.

Да, популярность языка не очень высока, но зато не страдает его качество. Мне очевидны преимущества Хаскеля по отношению к императивным языкам, большинство его проблем разрешимы, поэтому я уверен, что большая популярность ещё придёт по мере его развития.

Юрий Сыровецкий: Таким он видится только людям, ничего про него не знающим. В
«реальной» разработке Хаскель применяется давно, примеры легко найти в
вашей любимой поисковой системе. В частности, мы в ЛК использованием
Хаскеля довольны, и ничего другого на его месте не видим.

Игорь Шевнин: Что такое «язык для математиков» я толком не знаю. Это либо R/MatLab/Mathematica для расчётов и статистики, либо Python, потому что он простой и требует меньше инженерного бэкграунда. Но не Haskell. Алгебраические понятия типа моноидов используются в нём из практических соображений, а не только для дополнительной строгости.

Основную роль в популярности сыграла историческая распространённость C/C++/Java/C# в энтерпрайзе, они заняли нишу. Но сейчас многие компании начинают использовать Haskell и другие функциональные языки.

С каким япом ты бы сравнил Haskell и в чью пользу?

Джон Доу: Из более или менее распространенных — с Erlang. Но на Erlang все же проще писать и его проще выучить, как мне кажется.

Денис Мирзоев: Я хорошо знаю C, С++, Java и Haskell. C++ даже сравнивать ни с чем не надо, язык ужасен. Си — хороший язык для низкоуровневой разработки. В этой нише он будет лучше. В остальном я бы предпочёл Haskell.

Выбор между Java и Haskell уже труднее, но тут тоже нужно смотреть на конкретную задачу. Под андроид на Haskell будет скорее всего трудно писать, в этом случае лучше Java. А вот сервера писать на Haskell почти также удобно как и на Java. Если окружение позволяет — тулинг, доступность библиотек, — то я обычно выбираю Haskell.

Doctor_Ryner: С C#, достаточно погуглить, как реализовать Maybe на C# и на Haskell. Очень странно, что диктаторский чисто функциональный Haskell чувствуется гораздо более гибким и свободным. На самом деле это две крайности.

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

Игорь Шевнин: С Rust, пока что в пользу Rust. Он берёт очень многое от Haskell и других ФП-языков, но при этом дружит функциональный подход с императивным, а разработчики и сообщество намного грамотнее и более последовательно подошли к развитию языка с самого начала.

Что думаете про сообщество хаскелистов?

Джон Доу: Подавляющее большинство — очень дружелюбные люди, всегда готовые помочь. Приятное отличие от сообществ многих других языков.

Doctor_Ryner: Haskell сообщества зачастую содержат в себе пугающе умных людей, которые всегда готовы помочь. Не зря ходят локальные мемы про PhD, теорию категорий и академиков. Если заходя в чат по другим языкам, ты видишь, что люди обсуждают обычные production-проблемы и структуры данных. В чате по Haskell перед тобой сразу выскакивают монады, лемма Йонеды, аппликативные функторы, написание безумных типов и прочее-прочее.

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

Говорят, хаскелисты высокомерные. Правда?

Денис Мирзоев: Да. Мне кажется высокомерность связана с тем, что они очень любят свой язык и расстроены его недооценённостью.

Джон Доу: Нифига подобного.

Doctor_Ryner: Скорее всего такое мнение пошло, из-за того, что многих мейнстримных разработчиков сильно раздражает, когда хаскелисты начинают говорить о функциональном программировании и его преимуществах. Жуткое непонимание в свою очередь может раздражать самого хаскелиста, и он начнет бросаться терминами, за что его клеймят чсв.

Игорь Шевнин: Высокомерие — слишком сильное слово. Тут скорее дело в том, что ФП, ООП, различие ООП-классов и union types, extension problem и много других понятий однажды складываются в очень чёткую картинку, и после этого становится трудно воспринимать людей, которые пытаются противопоставить ООП и ФП или другим образом представить широкую проблему в узкой перспективе.

Почему ФП-языки до сих пор нишевые?

Денис Мирзоев: Их преимуществ всё ещё не достаточно, чтобы заинтересовать большое количество программистов. Трудность в изучении не способствует популярности. Проблемы с тулингом тоже многих отпугивают, а мне кажется как раз увеличение численности сообщества могло бы решить эту проблему. Получается замкнутый круг.

Игорь Шевнин: Нишевость постепенно проходит, а функциональные концепции подтягиваются в другие языки.

Doctor_Ryner: Сами функциональные принципы и языки, что их поддерживают, уже повсеместны. Даже для шарпов есть Linq и некоторые другие библиотеки. Нишевые скорее чисто функциональные языки, так как в них используются нестандартные концепции.

Не стоит забывать, что еще лет 20 назад железо было не достаточно производительным для функциональных языков, так что в мейнстрим функциональщина начала входить в последние годы, а интерес к Haskell только растет.

• Haskell
• Функциональное программирование
• Интервью

Где применяется «ленивый» язык программирования Haskell — о пользе лени или в каких отраслях и почему он востребован

Интересуетесь новыми языками программирования, которые помогут вывести бизнес на новый уровень? Обратите внимание на Haskell! Читайте подробнее, что это такое и где используется. Рассказывает ИТ-агентство BGStaff.

время на прочтение: 2 мин.

Haskell — это достаточно нестандартный язык с точки зрения тех, кто привык к JavaScript, С++, Python и прочим императивным разновидностям. Это обусловлено тем, что Хаскелл относится к функциональному типу. В статье подробно разберем особенности языка программирования Haskell. Расскажем, что это, в каких направлениях используется.

Что это за язык

Итак, Хаскелл принадлежит к категории функциональных языков. Программа, выполненная на нем — это набор функций в математическом смысле. То есть, как соответствий между элементами (аргументом и значением) 2-х множеств. Для получения значения функции имеются исключительно исходные данные вне зависимости от того, в каком порядке совершается вычисление.

Функция в данном языке программирования — основной структурный элемент кода. ИТ-сотрудник должен описать ее так, чтобы программе, которая переводит текстовые данные в машинный код, стало понятно:

• какие параметры переходят в функцию;
• какие действия с ними надо совершить;
• в каком формате предоставить получившийся результат.

Еще одна основная характеристика — «ленивость». Это означает, что функции вычисляются по мере их необходимости. Если сейчас не нужно знать значение определенной функции, она переносится «на потом». Именно это и называется «ленивым» или «отложенным» вычислением.

Приведем простой пример. Приложение «Калькулятор» предусматривает много функций (вычитание, умножение, деление и прочее). Однако если вам требуется именно сейчас только сложить цифры, будет выполнено лишь это.

Сферы применения

Часто Haskell используется в финансовом направлении. Его применяют банки и другие фирмы из отрасли финансов для разработки персональных инструментальных средств. Язык востребован в этой сфере благодаря гарантии верности вычислений без появления программных ошибок.

Хаскелл используют для генерации средств:

• обрабатывания текстовых файлов;
• синтаксического разбора;
• разработки систем антиспама.

Устройство Хаскелл дает возможность заложить в него языковые правила, в т. ч. и русского языка, научить алгоритмы находить связи с ними.

Создание средств для испытания программных языков — еще одно направление, в котором используется Haskell. В данном случае применяется тот же алгоритм, что и для обрабатывания текстовых файлов. Хаскелл способен работать не только с обычными, но и с программными языками.

WEB-разработка — еще один сектор, где применяется язык программирования Haskell. Он может использовать компилятор для JavaScript для открытия в браузере. На сервере же запускается в виде машинного кода, который оперативно обрабатывает множество параллельных подключений.

Востребованность программистов

Хаскелл — это язык стартапов, который активно внедряется в коммерческую разработку. За границей он уже пользуется высоким спросом, в России же только начинает набирать популярность. Хотя его первая версия и была выпущена еще в 1990 году.

Разработчиков Haskell набирают в штат крупнейшие корпорации, например:

• Яндекс;
• Ru Group;
• Avito;
• Just Work;
• ВКонтакте и другие.

Высокий спрос на IT-специалистов обусловлен тем, что Хаскелл отличается высокой точностью, устраняет риск возникновения программных ошибок. Haskell — достаточно новый язык, поэтому программистов, работающих с ним, не так много.

К тому введение в него не отличается простотой, поэтому за его изучение берутся не все. Из-за того, что спрос на IT-специалистов превышает предложение на трудовом рынке, работодатели готовы хорошо оплачивать работу таких сотрудников.

Где найти сотрудника в компанию

Найти сотрудников, которые работают с Хаскелл, достаточно непросто, что связано с небольшим количеством таких программистов в России. Доски объявлений и тематические сайты (HH и другие) обычно не дают результата при поиске.

Можно поискать кадры в сайтах Телеграмм, на форумах, посвященных этой теме. Однако это тоже не станет гарантией, что вакансию удастся быстро закрыть. Лучшим решением будет обратить в наше кадровое агентство BGStaff. Мы имеем широкую базу, поэтому сможем оперативно найти ИТ-специалистов, которые будут соответствовать всем вашим требованиям и справятся с возложенными на них задачами на 100%.

Найдем ИТ-специалистов любого уровня и направлений

• Работаем без предоплаты
• Первый кандидат через 3 дня
• Финансовая гарантия в течение 3 месяцев