Два года назад Haskell привлек меня своей отличной поддержкой параллельных вычислений и "ну не может быть call-by-need язык настолько сложным, как о нем говорят". Erlang после OZ "не пошел".

О Haskell также говорят, что это академический язык, мало пригодный на практике.
Как не пригодный? Ведь для него так много библиотек. Я мне много и не надо: поддержка работы с kqueue (epoll), LWP аналог, DBI, JSON и HTML парсеры.

Так как поддержка kqueue (epoll) появилась в GHC 7.x, то я взял Haskell и написал свое первое приложение. Правда для подстраховки перед этим сделал Perl вариант. Perl хорош тем, что дает много свободного рабочего времени, чтобы заняться Haskell. С третьей попытки Haskell версия стала выглядеть не хуже Perl версии, и даже немного лучше, и имела производительность в два раза выше. Но из-за кривой Python библиотеки, используемой клиентом, пришлось на сервере включить буферизацию и производительность упала в эти два раза. Но зато осталось отличное использование памяти. Все стлало работать отлично, после того как разработчики GHC сообщили, что kqueue в GHC 7.0.1 по умолчанию не используется, а активируется косвенно в threaded режиме.

Но вернемся к Haskell. Haskell в первую очередь академический язык. А в академиях свои порядки: в год необходимо опубликовать не меньше столько-то статей, размер диссертации должен быть не меньше столько-то страниц, литературных источников нужно не меньше такого-то количества. А кто их все читает эти литературные источники, в большинства случаев? Так, по парочки страниц в каждом.

Такое впечатления, что те, кто пишут на Haskell, по диагонали читают статьи и о самом Haskell. Это относиться, к сожалению, и к авторам base пакета. Чувствую, что преувеличиваю, но факт остается фактом: используя совет из документации, сразу словил ситуацию гонки. Хорошо, что недавно читал статью про асинхронные исключению. Но это прошлое, написанный сервер без проблем работает полтора года, так что вернемся в настоящие.

С быстрым HTML парсером мне помог vshabanov.livejournal.com, большое спасибо ему.

Сейчас мне нужно работать с базами данных (Pg и MySql). Для работы с базами рекомендуют использовать HDBC и Takusen, но в последнем нет поддержки MySql. Недавно появились postgresql-simple и mysql-simple. Берем проверенный временем HDBC, о котором написано, что он сделан по образу и подобию Perl DBI, но лучше, так как использовался опыт Python's DB-API v2, JDBC in Java.

Ой! Где в HDBC поддержка prepared statement на стороне сервера?! Я не требую поддержки асинхронность, которая давно есть в Perl DBD::Pg и в упрошенном, но достаточном виде, 2 года как появилась в DBD::mysql и самом DBI. Я хочу лишь поддержку prepared statement на стороне сервера, баз которой быстрая работа с базами данных не возможна.

Справедливости надо сказать, что в Takusen есть поддержка prepared statement на стороне сервера и для PostgreSQL, и для Oracle.

Но как-же HDBC? Для postgresql нет вообще, а для mysql, сюрприз, есть. Но какая. После execute сразу вызывается mysql_stmt_close, что делает все prepared statement одноразовыми. Да и самом HDBC не предусмотрена поддержка этого. Чтобы ее добавить придется согласовать действия автором всех HDBC пакетов.

Если сравнивать с Perl DBI, то такое ощущение, что вернулся в прошлое.

Что делать? Какие меня ждут впереди неприятные сюрпризы от Haskell? Стоит время тратить на Haskell или использовать Perl с IPC::MPS, EV, Coro и DBI?
Ведь имея IPC::MPS, который я написал по мотивам Erlang и OZ, и при наличии MultiAgent (Multiplicative Agent поверх IPC::MPS), написанного с оглядкой на OZ, с учетом их интеграции с EV и Сoro, мой Cloud Perl не хуже, чем Cloud Haskell. :-)

Ну, что же с тобой делать, Haskell? Стоит ли твой игра свеч? Я в замешательстве и раздумьях...

P.S.
Оказывается в Python библиотеках также не используется prepared statement на стороне сервера.
Теперь понятно, почему люди говорят, что NoSQL быстрей YesSQL, а мои тесты говорят, что PgSql и MySql дают не производительность не хуже

Немного о себе
--------------

Никогда не думал, что стану программистом. Я химик по образованию. Но вот уже лет 11 как профессионально занимаюcь программированием на Perl (сайты НЕ делаю).

Мотивация
---------

Как-то подумалось, если я часто использую лишь функциональное подмножество языка языка Perl, то почему бы не взять для этих задач Haskell?

Аргумента "за":

- скорость программ;
- легковесные потоки, масштабируемые на множество CPU;
- автоматическая оптимизация хвостовой рекурсии (в Perl 5 делается руками, будет в Perl 6);
- COW (будет в Perl 6);
- автоматический карринг;
- не нужно писать лишние закорючки при работе с функциями, как с сущностями высшего порядка;
- тотальная ленивость.

Да, кстати, с выходом GHC 7 мы получили интеграцию легковесных потоков в kqueue и epoll.

Аргумент против один: страшные и ужасные загадочные монады.
Пытался читать о них 3 года назад. Какие-то космонавтики в скафандриках. Корзинки и ящички с яблоками и ягодами. Мир, разделенный на два части: чистых и не-чистых. Ничего не понял.

Не так страшен черт, как его малюют
-----------------------------------

После очередной неудачной попытки разобраться с монадами, почему они так нужны для IO в Haskell, плюнул на все это.

А в голове крутилась одна мысль. Я начал использовать ленивость на Perl этак лет 8-9 назад (тогда я не знал о Haskell).
Почему у меня не возникало проблем с IO? Ведь порядок общения с внешним миром легко определятся при помощи продолжений!

Стал сам разрабатывать простой ленивый язык и компилятор для него. Да что там разрабатывал - просто все, что делал на Perl вручную, делегировалась компилятору. На удивление система получалась простая.

Почему же в Haskell все так сложно?! Спасибо умные люди подкинули ссылки на пару статей, среди них "Call-by-need and Continuation-passing Style". После прочтения которых в голове все прояснилось. В Haskell тоже все просто! Читать надо первоисточники, а не перепевы.

Проверка в реальном деле
------------------------

Есть у меня мультиплексирующий прокси-сервер "Redis Sharding" (http://github.com/kni/redis-sharding).
Написан он на Perl, с использованием замыканий. Попробую я переписать его на Haskell.

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

Сначала взялся как обычно за самую трудную часть: управление соединениями и потоками данных.

Код на Haskell показал производительность выше в 2 раза, но вот объем кода в строках был в 1.5 раза больше, а в словах в 2 раза.
Что для мене не приемлемо. Да и выглядело это вся ужасно.

После чего решил вместо изменяемых замыканий использовать легковесных потоки. Сделал такой себе маленьких Erlang на Haskell (слава Богу подобных опыт на Perl был). Клод стал чище, а количество срок стало таким как у Perl варианта, но не слов.
Но если управление дочерними потоками вынести в отдельную библиотеку, а я ведь буду часто его использовать, то объем кода можно считать одинаковым (в словах 7% не в пользу Haskell). Да, код стал чище, но появилось много потоков, я чтобы не запутаться пришлось даже написать описание взаимодействия между ними. Кстати скорость выполнения немного повысилась, так как библиотека для работы с сокетами заточена под многопоточность, что приводили в мультиплексирующем варианта к дублированию проверок на возможность читать-писать.

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

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

И вот тут на помощь приходит ленивость и Network.Socket.ByteString.Lazy. Теперь парсер работает с данными, так как будто они уже все есть в наличие. Размер фрагмента второй части стал до безобразия маленьким. Даже не удобно сравнивать с энергичными языками. Разве что можно сравнивать с Mozart-OZ, в котором используется data-flow execution, но в нет пока нет поддержки ByteString.Lazy и kqueue/epoll. Благодаря этой части удалось догнать Perl вариант по выразительности и краткости кода.



Вывод
-----

Если использовать ленивый язык, то использовать ленивость по полной!

Не надо использовать изменяемые замыканий, когда есть легковесный потоки.

Не надо использовать напрямую System.Event - ведь есть легковесный потоки.

При соблюдении этих условий, на Haskell можно достигнуть выразительности и краткости кода не уступающей Perl.


Развеивая мифы и заблуждения
----------------------------

О Haskell существует множество мифов, о нем рассказывают множество небылиц. Попробуем разобраться где истина, а где заблуждения.

1. Необходимость ученой степени в области Computer science. Это не правда. Достаточно просто ученой степени. :-)

2. Сложность. Это тоже не правда. Haskell - простой и красивый язык. На столько простой, что на нем очень легко и удобно создавать высокоуровневые абстракции, простые и сложные. Последние, разумеется, затуманивают разум новичков и вводят в заблуждения о простоте и сложности самого языка.

3. Ужас монад... Даже и не хочется касаться этой темы. Скажу только одно: не читайте всякую фигню, читайте первоисточники.

Влияние же остальных мифов не так пагубно для присматривающихся к Haskell, поэтому их рассматривать не буду.

Какова же причина появления этих мифов и заблуждений? На ум приходит только одно: Haskell настолько прост, что многим трудно это осознать.