Прагматизм и Haskell
Jun. 12th, 2012 11:13 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
iamjaphДва года назад 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 дают не производительность не хуже
О 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 дают не производительность не хуже
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-06-12 09:25 am (UTC)Как не пригодный? Ведь для него так много библиотек.
Ну, лет 10—15 назад был только один package, который сейчас называется base, и иерархических имён модулей не было. А говорят так потому, что взгляды людей консервативны, они меняются медленнее, чем ситуация в мире. По этой же причине люди не могут предсказать, что будет с Haskell через 10 лет. Для этого надо всего лишь предсказать действия всех людей. Глоба нагадает вам не хуже, чем топовый кодер. ;)
no subject
Date: 2012-06-20 09:35 am (UTC)Вот именно так, чтобы одно и то же работало и с тем, и с другим?
> postgresql-simple
Там тоже нет поддержки PREPARE.............
Не то, чтобы очень сложно дописать, но я не доверяю библиотекам, создатели которых настолько оторваны от практики.
> PgSql и MySql дают не производительность не хуже
А в 9.2 уже есть index only scan! ;-)
Мне не нравится из этих SQL-библиотек ни одна.
Точно так же, как и нет нормального GUI.
За MySQL не скажу, стараемся его не использовать без особой причины, а вот с поцгресом очень так замечательно работать через тупой биндинг к libpq.
Если только нет кучи всякоразных структур, как в мегаоперденях от р. metaclass, то могу даже и довольно-таки рекомендовать.
Правильно с SQL работать не так, но для базок средней сложности правильное решение (генерация библиотеки по структуре табличек) имхо будет overengineering'ом.
no subject
Date: 2012-06-20 10:57 am (UTC)no subject
Date: 2012-06-20 11:35 am (UTC)http://hackage.haskell.org/packages/archive/postgresql-libpq/0.8.2/doc/html/Database-PostgreSQL-LibPQ.html
вполне может называться тупым биндингом.
А в окамелёвой части, кстати, таки свой биндинг к libpq, поскольку (по крайней мере, на тот момент) существующие не устраивали, по разным причинам.
no subject
Date: 2012-06-22 10:46 am (UTC)Я заметил, что вы удалили пост из ru_lambda. Интересно узнать, почему.
Некоторые комментарии там действительно были дурацкие, но все же удалять посты не совсем, что ли, этично, мне кажется.
Успели ли вы прочесть мой комментарий с решением вашей проблемы? Он вроде как скрытым оставался.
no subject
Date: 2012-06-25 10:57 am (UTC)Да что-то показалось, что глупый вопрос задал, хотя, да, надо было не удалять.
Просто вспомнил, как когда-то некоторые фразы ператащили на ЛОР и перекрутили (это когда я перловый сервер переписывал на haskell).
Что-то как-то не складывается с haskell у меня. Когда используешь, что-то базовое - все нормально.
Стоит копнуть дальше - засада на засаде.
К сожалению, ваш коментарий не увидел. Буду благодарен, если вы расскажите еще раз.
no subject
Date: 2012-06-25 08:34 pm (UTC)Но если вкратце, то
no subject
Date: 2012-06-26 06:14 am (UTC)