Взялся писать статью про разработку Beep-а, довольно бодро написал процентов 70% текста, но внезапно начал сдуваться, при мысли, что то, о чем я пишу, на самом деле достаточно банально и малоинтересно. Ну стояли задачи. Ну решились задачи. В принципе ФП непричем — написать можно было бы на любом языке, настоящие перцы пишут компилятор на том же языке, который разрабатывают. Как-то непонятно, как писать, что бы было интересно.

Статья задумывалась, как некая success story применения функционального языка, но пока вышло в стиле Че Бурашки — "мы строили, строили и наконец построили".

С одной стороны — разрабатывать компиляторы достаточно интересно. С другой стороны, писать какую-то ахинею в стиле хабра, "пишем компилятор — делай раз, пишем компилятор — делай два" — тоже глупо. Все сто раз написано, никаких откровений нет и почитать исходники Haxe, Language Zoo, mincaml и TAPL — в сто раз полезнее и не надо тратить время на воду.

Каких-то то откровений в плане функционального дизайна предъявить тоже не получается, поскольку функциональному программированию я и учился по мере написания Бипа, а один из восьми рефакторингов был направлен на то, что бы убрать овердизайн. K.I.S.S, здравый смысл, прототипирование и отказ от решения ненужных задач и концентрация на нужных — вот и весь дизайн.

Как язык, Бип не примечателен ничем, кроме вывода типов, а за этим не ко мне, а к TAPL. Если в нем что-то есть интересное — то это рантайм и способность бодро работать на слабых процах с минимальной памятью — а то для журнала неформат — ведь рантайм-то на обычном Си, да и в нем тоже нет особых откровений — просто взял самое лучшее из самого простого, так как был уверен что изощряться можно только после того, как вообще заработает и будет чего-то не хватать. Пока хватает.

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

Если кому-то это интересно — может быть отпишитесь в паре строк, в каком ключе было бы интереснее видеть статью. Какие аспекты раскрыть, какие — малоинтересны. Может я опять слишком умничаю, и надо просто десяток листингов — "вот тут мы строим AST, вот тут его обходим, вот так в окамле выглядит паттерн-матчинг" ?

Здравствуйте, dmz, Вы писали:
dmz>С одной стороны — разрабатывать компиляторы достаточно интересно. С другой стороны, писать какую-то ахинею в стиле хабра, "пишем компилятор — делай раз, пишем компилятор — делай два" — тоже глупо. Все сто раз написано, никаких откровений нет и почитать исходники Haxe, Language Zoo, mincaml и TAPL — в сто раз полезнее и не надо тратить время на воду.

Сто раз написано и прочитано людьми которые в теме. И обычно в книгах рассматриваются абстрактные вещи. А Beep лично мне был бы интересен как success story. Какие решения принимались, какие были грабли, как получилось с минимальными телодвижениями сделать хорошую вещь.
Функциональная часть может состоять в объяснеии почему был создан язвк с выводом типов, какие это дало плюшки по сравнению с допустум чистым С. Объяснить, что вывод типов вытянут из функциональных языков, и кому стало интересно смотрите TAPL, ссылкочка на амазон, ссылочка на перевод.

Ну и почему для создания пользовался окамл, а не питон или руби или с++
Некоторые мои знакомые которые интересуются ФП хотели бы увидеть именно такие истории успеха, с пояснением почему ФП — рулез. Ибо статьи про пользу моноидов в Хаскеле это круто, но для начинающих имеет слабую практическую ценность. А для того, чтобы осознали, необходимы живые практические примеры. С хорошим объяснением и кучей ссылок куда смотреть дальше.

dmz>Каких-то то откровений в плане функционального дизайна предъявить тоже не получается, поскольку функциональному программированию я и учился по мере написания Бипа, а один из восьми рефакторингов был направлен на то, что бы убрать овердизайн. K.I.S.S, здравый смысл, прототипирование и отказ от решения ненужных задач и концентрация на нужных — вот и весь дизайн.

Это объяснение отлично все проясняет для тех, кто уже понял как звучит хполок одной ладони Но для начинающих просто набор слов. что значит убрать овердизайн ? Как определить нужность задачи ? Нафига нужно прототипирование?
Понятно дело, что если углубляться в каждый из этих вопросов можно написать книгу и не одну по каждому пункт. Но хотя бы очертить направление мысли стоит.

Ну, вот так как-то.

M>И обычно в книгах рассматриваются абстрактные вещи.

Ну нет, с этим не согласен. Тот же TAPL с примерами — куда уж конкретнее.

M>А Beep лично мне был бы интересен как success story.

Story-то оно, конечно, success, но как-то тоже банально. Надо — не было — сделали — теперь есть. Драматизма не хватает как-то.

M>Функциональная часть может состоять в объяснеии почему был создан язвк с выводом типов, какие это дало плюшки по сравнению с допустум чистым С.

Где-то так оно примерно и есть, это внушает надежду, что статья все-таки состоиться.

M>Объяснить, что вывод типов вытянут из функциональных языков, и кому стало интересно смотрите TAPL, ссылкочка на амазон, ссылочка на перевод.

Но много ли будет пользы, если я упомяну, почему вывод типов сделать разумно на ФЯ, но не буду вдаваться, что такое вывод типов и как он работает?
А сильно вдаваться я не хочу, лучше, чем у Пирса все равно не получится.

M>Ну и почему для создания пользовался окамл, а не питон или руби или с++

А вот тут я боюсь раздуть флейм. Особенно с моим отношением ко всем трем.

M>Это объяснение отлично все проясняет для тех, кто уже понял как звучит хполок одной ладони Но для начинающих просто набор слов. что значит убрать овердизайн ? Как определить нужность задачи ? Нафига нужно прототипирование?

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

M>Ну, вот так как-то.

Спасибо!

Здравствуйте, dmz, Вы писали:

dmz>Если кому-то это интересно — может быть отпишитесь в паре строк, в каком ключе было бы интереснее видеть статью. Какие аспекты раскрыть, какие — малоинтересны. Может я опять слишком умничаю, и надо просто десяток листингов — "вот тут мы строим AST, вот тут его обходим, вот так в окамле выглядит паттерн-матчинг" ?

Для меня идеал такого рода статьи — Xavier Leroy. The ZINC experiment: an economical implementation of the ML language.
Это исходники прообраза Caml-light, circa 1990, облитературенные до объема 110 страниц. Главное писать какие решения, компромиссы etc. были приняты и почему.

Традиция такого рода литературы, была заложена Lions' Commentary on UNIX 6th Edition, with Source Code.

Здравствуйте, dmz, Вы писали:


dmz>Story-то оно, конечно, success, но как-то тоже банально. Надо — не было — сделали — теперь есть. Драматизма не хватает как-то.

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