Haskell: жёсткий разбор

Чтобы разобраться, каким должен быть идеальный язык, давайте посмотрим на недостатки сегодняшнего мэйнстрима. Начнём, как водится, с Хаскеля.

На хаске хорошо писать обфурцированные исходники — уже на следующий день даже автору бывает сложно разобраться в собственном коде, не говоря уже о других программистах. Всё в нём, от автоматического карринга до ленивых вычислений, всячески этому способствует. Синтаксис, в духе .&. или <|>, этому тоже хорошо помогает. Тотальное каррирование только провоцирует запутанное кодирование, когда вызов с некорректным количеством аргументов приводит к трудно понимаемым ошибкам в совершенно других местах кода. Точки-с-запятыми тоже можно опускать, что ещё более затрудняет понимание.
Вообще, чрезмерно сложный синтаксис этого языка существенно усложняет синтаксический анализ (что для программиста, что для программы), а также практически отключает потенциал метапрограммирования.

GHC генерирует медленный код, который вдобавок допускает утечки памяти. Будьте готовы к проигрышу в производительности в сотни раз в сравнении с С++. Тут же плохая совместимость как на уровне самого компилятора GHC, новая версия которого вполне может отказаться транслировать старый код, так и в плане зависимостей внешних пакетов, которые часто приходится согласовывать/версионировать вручную.

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

Вроде бы самое вкусное — система типов. Однако на практике она больше провоцирует потоки ошибок компиляции и сборки, да и для замены тестирования задействовать её тоже не выйдет. Что толку, если мы добьёмся соответствия системы типов нашего проекта математической модели, но не сможем отловить прозаические деления на ноль? Когда проект большой, без тестирования не обойтись, тайп чекинг ему не замена.

Вдобавок, на практике type driving development — это практически пустое поле, в реальности в Haskell-проектах система типов часто превращается в обузу. Фактически, вы наоборот ограничиваете свои возможности невысокой выразительностью системы типов. По этой причине Хаскель не подходит для быстрого прототипирования или проектов, где требования часто меняются (а это 99% проектов!). Именно поэтому, кстати, и была собственно придумана в своё время динамическая типизация.

Пожалуй, по типизации Haskell даже уступает динамически типизированным языкам! Например, вы не можете добавить в уже действующий проект динамическую область видимости (type-safe конечно) без рефакторинга всей программы. Позднее связывание и утиная типизация ситуацию только ухудшают.

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

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *