![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Немного о себе
--------------
Никогда не думал, что стану программистом. Я химик по образованию. Но вот уже лет 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 настолько прост, что многим трудно это осознать.
--------------
Никогда не думал, что стану программистом. Я химик по образованию. Но вот уже лет 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 настолько прост, что многим трудно это осознать.
