[spoiler]Но при этом у Haskell есть и немало оппонентов, которые отмечают его слабые стороны -- и что интересно, минусы Хаскела, озвученные практиками, едва ли не полностью противоположны красивостям, нарисованным Andy Adams-Moran в eWeek (см. вчерашний пост).
Примерно передам эти мнения: компактность кода приводит к ужасающему синтаксису; монады призваны формализовать побочные эффекты, однако сама возможность их использования снижает общую надежность программы; запутанность многих программных механизмов; кошмарность зависимостей между пакетами; стандартные библиотеки не такие уж и целостные…
А уж сложность доступа и редактирования вложенных полей хаскеловскому коммьюнити известна очень хорошо и очень давно, однако проходят годы, и несмотря на уверения Adams-Moran, проблема эта никак не решается.
Ленивые/отложенные вычисления -- также вещь обоюдоострая. А главное, что проблемы с ними начинают особенно остро проявляться, когда проект становится большим. Тогда у разработчиков будут улетать дни и дни на тюнинг этого механизма под нужную задачу. А ведь отладка его совсем не тривиальна. В результате же преимущества "ленивого" подхода нивелируются большими проблемами с общей эффективностью системы.
Резюме по Хаскелу приверженцы этого языка формулируют так: Haskell делает простые вещи сложными, а сложные вещи -- простыми.
Кстати, развернутую, но доброжелательную критику Хаскела давно ведет в своем блоге профессор Роберт Харпер из Карнеги-Меллона, и силами энтузиаста Владислава Натарова этот блог переведен на русский. Любители функционального программирования, почитайте обязательно, очень интересно!
То есть если не стоит задача оптимизации системы в сотни и тысячи раз, лучше пользоваться "более классическими" языками. Но вот когда надо решить узкоспециализированную задачу, лучше всего помогут, пожалуй, мощные функциональные языки. К такой задаче, кстати, следует отнести обещание Агентства национальной безопасности США взломать алгоритм AES.
Эксперты полагают, что классическая криптоатака на этот алгоритм пока обречена на неудачу, слишком много требуется машинного времени и ОЗУ на такой взлом, и вряд ли в ближайшие десять лет ситуация изменится. Но вполне возможна успешная атака на реализации этого алгоритма (поиск сторонних каналов, анализ схем генерации ключей, использование слабостей генератора случайных чисел, плохие пароли, …), на конечные точки в системе связи, на уязвимости программного кода (что делает особо актуальными DSL-языки, упрощающие автоматическую генерацию кода) итп.
Кроме того, АНБ готовит аппаратные системы взлома ключей RSA-1024, и реализация соответствующих алгоритмов на машинном уровне например на Хаскеле может быть одной из самых оптимальных.
Кстати, интересное сравнение темпов взлома конкретного ключа RSA-1024 любительской(!) системой -- от 6 лет в 2011-м до 10 минут в 2013-м.
Далее -- есть ли альтернативы Хаскелу?
Монады делают программирование по сути императивным. Какой смысл на Хаскел переходить тогда?
Да, те куски которые без них, смотрятся поначалу более абстрактно и алгебраически но тут вступает в игру ленивость.
> Ленивость
Ленивость для понимания программы увы требует понимания подкапотной механики Хаскеля.
Опять - же, в чем тогда предполагалось упрощение и облегчение по сравнению с императивными
языками? А раз тоже сложно, зачем тогда Хаскел? Абстрагироваться то в достаточной степени
от механики не удалось, преимущества ФП не реализовались?
Хаскел НЕ дает того облегчения параллелизма и многого прочего что обещал.
И как раз ленивость все и усложняет вопреки обещаниям.
Старички вспомнят возможно похожую историю с Прологом и его недетерминизмом.
Тоже ведь - типа декларативный, программа умеет считать больше чем планировалось
и так далее. Маркетинг. Хаскель - это просто новый чудо-вариант Пролога?
Нет, языки со сложными внутренними механизмами не приживаются в массах, имхо.
У них есть своя ниша но программы на них более непредсказуемы и тяжелее
поддерживаются. Статическая типизация тут не спасет - все равно по определению
больше комбинаторных вариантов путей исполнения программы и модифицировать
так чтоб все они продолжали работать - сложнее.
> Альтернатив хаскеллу
МЛ семейство языков ничуть не хуже Хаскеля. Только не стоит искать в нем фичи Хаскеля, это глупо.
В нем свои подходы и свои решения своих проблем. По факту - вполне юзабельно.
именно так, все слова тут правда. Конечно, внедряльщики ООП в свое время громко кричали и писали что все как раз наоборот. но... "хоть сто раз скажи - халва! во рту слаще не станет". ведь они просто зарабатывали на этом. а хитрые программисты "зарабатывали" потом на платной поддержке сложных ООП программ)) ООП - это методика механического доения заказчика.
если не лениться обдумать эти обещания то:
1) Наследование по самому своему определению нарушает модульность, в одну сторону.
Поскольку контракт между родителем и потомком не выписан явно, по этому каналу
могут бродить неожиданные сюрпризы при модификациях))
2) посыл сообщения это как goto, эта абстракция может быть использована конечно но она
ничем не облегчает разработку и поддержку параллельных программ, как не облегчал и goto
обычные ассемблерные программы.
никакого контроля схем взаимодействия при модификациях, кроме ручного.
и вполне естественно, быстрее получается бардак, как в ассемблере по сравнению с паскалем.
да и вообще - те кто хоть раз в жизни писал параллельные программы (например, я),
знает что основная задача распараллеливания как раз развязывание зависимостей и состояний.
передача сообщения есть синхронизация состояний. чем больше синхронизаций тем меньше
коэффициент распараллеливания.
поэтому параллельщики всегда пишут для себя либы со своими абстракциями для параллелизма.
и потом уже в программах только их используют, не лазя внутрь и не меняя схемы обмена сообщениями.