Не написать ли статью для The Monad Reader ...

[dastapov]

... на тему "Haskell как rapid development/prototyping tool in real life"?

Тут у жены на работе народ пишет некую софтину, работающую с данными сложной структуры и больших объемов.

Формат данных описыватся на неком местном DSL (domain-specific language), представляющем собой горячечный бред на тему EBNFи ASN.1. Соответственно, интегральной частью софтины является парсер файлов-описаний формата, и проверка/обработка этих описаний в соответсвии с некоторым набором бизнес-правил (достаточно простых, типа "все поименованные поля должны быть где-то упомянуты")..

Язык - java, парсер и сопредельные структуры данных и алгоритмы - на основе javacc. Этот кусок пишется среднепотолочным програмистом на ява в течении двух недель (грамматика - около 150 продукций).

После написания встает вопрос проверки того, что написали. Заказчики стали присылать примеры файлов, и с каждой новой пачкой примеров стали вылазить какие-то изменения в грамматике, при внесении которых в код стал ломаться парсинг старых файлов и т.п. В результате наступил момент, когда на руках имелся код, неизвестно - работающий или нет, описание грамматики - неизвестно, валидное или нет, и некоторое кол-во файлов-примеров.

Тут я предложил провести эксперимент. Мы сели и я за вечер (часа 3-4) написал парсер этого DSL (haskell, parsec), который успешно парсил все имеющиеся на руках примеры. В процессе было выловлено с десяток лаж в описании грамматики.

После этого, за два следующих вечера (тоже по 3-4 часа) был написан (haskell, QuickCheck) генератор псевдослучайных правильных и неправильных файлов, на которых тестировался парсер, написаный на java. В процессе было выловлено несчетное кол-во лаж и разнообразных corner cases, на которые либо не был рассчитан javacc "в стандартной конфигурации", либо о которых попросту никто не думал.

В результате java-девелоперы неделю фиксили баги в режиме "мы все починили! - а ну-ка, сгенерим новую порцию в 100 файлов и еще раз проверим. - ой, опять что-то поломалось",

Жена заработала код без багов. Я заработал "респект и уважуху", кучу моральных бонусов и опыт использования QuickCheck для генерации тестовых примеров.

UPD: статью написал, выложил на haskellwiki. Читать можно тут

Comments

[dinozavrik.livejournal.com]

Интересно, но есть пара вопросов
а) неужели в жабе не было подходящих библиотек для парсинга?
б) что известно насчёт квалификации этих жаба-девелоперов?

И ещё. Хотелось бы - если есть возможность - сравнить два куска кода с примерно одинаковой функциональностью (в данном контексте). На жабе и на хаскелле. Или, если код слишком долго выцарапывать - то хотя бы сравнительное описание, как пишется на одном и как на другом.

[http://users.livejournal.com/_adept_/]

1)Подходящая библиотека для парсинга - это как раз JavaCC :)
2)Квалификация - среднепотолочные software engineer с 2-3 года "явы fulltime" за плечами

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

Допустим, я слабо представляю, в каких структурах данных хранить то, что мы напарсим (вот, взяли в зубы описание грамматики и поехали писать). На haskell я могу, грубо говоря, написать:
megaParser =
do a <- parseHeader
b <- parseBody
c <- parseTrailer
return (a,b,c)
, потом програмируя "top-down" определить все недостающие функции, допинать его до состояния "копилируется", а потом спросить у компилятора - так какого же типа получилось возвращаемое значение у 'megaParser'? Помедитировать над этим, и описать нормальную структуру данных.

Если вдруг выяснится, что в парсере надо что-то поменять (например, где-то вместо "выражения" возвращаем список из "(имя, выражение)", то, как правило, мне надо внести пару локальных правок, и все работает - type inference за меня позаботится о том, чтобы вывести и проверить типизацию по всей программе.

Что мы имеем в этом случае в яве? В яве мы имеем, как правило, кучу мелких правок, разбросаных по всему коду, что резко снижает скорость внесения изменений и уверенность в том, что мы ничего не поломали (сорри, что без примеров и возможно путано, но кто хоть раз такое делал, сразу поймет, о чем я).

Что же касается кода, то из JavaCC можно получить haskell-евский parsec 2-3-5ю поисками с заменой по regexp-у + легкой обработкой напильником.

Главный кайф бы не в том, насколько легко написать парсер. Кайф был в том, насколько легко его модифицировать, и насколько легко его (и его java counterpart) протестировать.

[dinozavrik.livejournal.com]

Ага... это интересно. Хотя пока что для меня это смахивает больше на syntax sugar, нежели на серьёзные преимущества, тем не менее...

В общем, что бы такого почитать по хаскелю программисту C++ с пятилетним стажем - чтоб без баянов, а сразу о преимуществах? :)
Причём преимущества интересуют не для научного софта, и не для "доказательств правильности", а для более приземлённых вещей - десктопных приложений, или даже игр... игры на нём писать реально вообще?

Что читать

[http://users.livejournal.com/_adept_/]

1)www.haskell.org/tutorial (рекомендую TAHT - yet another haskell tutorial, или haskell-v8 (хотя последний, возможно, еще в широкий доступ не выложен))

2)Про преимущества можно почитать статью "why functional programming matters?"

3)Про игры: http://www.haskell.org/hawiki/Frag

Re: Что читать

[stoune.livejournal.com]

Та я вже просік, що функціональне програмування може полекшити життя, тільки чомусь Хаскель як предмет для вивчення навіть не брався до уваги, бо не побачив на ньому жодного цікавого для мене продукту. В результаті зупинився на ErLang, все таки заточений під мою сферу діяльності, комунікації і на ньому написаний ejabberd мабуть кращий з фрішних jabber-серверів і потреба доробити напильником під потреби організації змусили сісти за його вивчення.

Что читать (часть 2)

[http://users.livejournal.com/_adept_/]

Хороший список для старта лежит тут: http://www.haskell.org/hawiki/FirstSteps