![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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. Читать можно тут
Тут у жены на работе народ пишет некую софтину, работающую с данными сложной структуры и больших объемов.
Формат данных описыватся на неком местном 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. Читать можно тут
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-01-16 10:52 pm (UTC)Дык!
Date: 2006-01-18 10:47 pm (UTC)Язык, похоже, кривоват в час ночи, но читать (судя по отзывам на #haskell) можно :)
(no subject)
Date: 2006-01-17 05:42 am (UTC)Пацан сказал - пацан сделал :)
Date: 2006-01-18 10:48 pm (UTC)Я вот в раздумиях, стоит ли наливать больше воды. или и так пойдет?
Re: Пацан сказал - пацан сделал :)
Date: 2006-01-19 07:34 am (UTC)(no subject)
Date: 2006-01-17 09:18 am (UTC)Я, собственно, так и решил сделать
Date: 2006-01-18 10:48 pm (UTC)(no subject)
Date: 2006-01-17 09:35 am (UTC)а) неужели в жабе не было подходящих библиотек для парсинга?
б) что известно насчёт квалификации этих жаба-девелоперов?
И ещё. Хотелось бы - если есть возможность - сравнить два куска кода с примерно одинаковой функциональностью (в данном контексте). На жабе и на хаскелле. Или, если код слишком долго выцарапывать - то хотя бы сравнительное описание, как пишется на одном и как на другом.
(no subject)
Date: 2006-01-18 11:04 pm (UTC)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) протестировать.
(no subject)
Date: 2006-01-18 11:29 pm (UTC)В общем, что бы такого почитать по хаскелю программисту C++ с пятилетним стажем - чтоб без баянов, а сразу о преимуществах? :)
Причём преимущества интересуют не для научного софта, и не для "доказательств правильности", а для более приземлённых вещей - десктопных приложений, или даже игр... игры на нём писать реально вообще?
Что читать
Date: 2006-01-19 09:31 am (UTC)2)Про преимущества можно почитать статью "why functional programming matters?"
3)Про игры: http://www.haskell.org/hawiki/Frag
Re: Что читать
Date: 2006-02-19 08:01 pm (UTC)Что читать (часть 2)
Date: 2006-01-21 10:57 pm (UTC)