Концептуальное о ваших этих хаскелях и окамлах

[metaclass]

haskell datagrid

ocaml datagrid

Обратите внимание на количество найденных ссылок. И попытаться найти хотя бы одну из них которая соответствует искомому.

Я, конечно, понимаю, что заниматься мерянием производительности алгоритмов и разработкой сложной back-end логики это гораздо интереснее, чем делать GUI, но GUI тоже таки делать нужно.
У меня вот в последней сложной фиче, которую я делал, на back-end логику ушло пару дней, на ввод данных для нее - неделя и еще две недели на подгонку GUI чтобы это все было можно использовать как можно удобнее и быстрее.

Comments

[aamonster.livejournal.com]

Почитал комменты... Лучшим решением видится тупо ждать.

Самому периодически императивщина становится неудобной. В частности - в приложении к GUI. Обработчики событий, меняющие некие данные, что, по хорошему, должно дергать другие обработчики, менять еще данные и так далее - в общем, приходится или усложнять код, или каждый раз делать большой пересчет, теряя в производительности и скорости реакции на действия юзера. А если описать то же самое на чем-то типа языка make-файлов, то все оказывается просто и элегантно...

Кстати, насчет "ждать": я бы скорей поставил не на развитие всяких ML с Хаскелями, а на появление в .net декларативных средств. Кажется, тут движение пошустрее.

[kurilka.livejournal.com]

F# же потомок ML?
Или речь о чём-то ином?

[aamonster.livejournal.com]

Да, границу и правда трудно провести =).
Хотя я, скорее, имел в виду постепенное добавление декларативных средств в C# - вон, и лямбды уже есть, и еще какие-то радости.

[metaclass.livejournal.com]

Готового работающего нет.

Но в ту сторону я полез именно за тем, чтобы придумать способ описания этого конечного автомата с участием пользователя, т.к. в FP как раз это все более математизировано, чем в привычных языках программирования.

[metaclass.livejournal.com]

Готового работающего нет.

Но в ту сторону я полез именно за тем, чтобы придумать способ описания этого конечного автомата с участием пользователя, т.к. в FP как раз это все более математизировано, чем в привычных языках программирования.

[kkirsanov.livejournal.com]

--конечного автомата с участием пользователя, <...> FP как раз это все более математизировано

В умных книжках пишут что ФП и автоматы - две вещи несовместные, т.к. у автоматов состояния есть, а в ФП их быть не должно.

[kurilka.livejournal.com]

можно ссылки на эти "умные книжки"?
Монады State и gen_fsm в эрланге, наверное, не существует?

[kkirsanov.livejournal.com]

--можно ссылки на эти "умные книжки"?
Боюсь что уже не упомню. Помню что по-английски было.

Обосновывлось так: если у вас сплошные состояния то это уже к товарищу Тюрингу и всякой императивщине, всяческими костылями конечно запихнуть в ФП можно, но зачем?

--Монады State и gen_fsm в эрланге, наверное, не существует?
Конечно существуют.

[kurilka.livejournal.com]

Я правильно понимаю, что эквивалентность лямбда исчисления и машины Тьюринга для вас пустой звук?
Про костыли интересен более полный ответ - что вы ими считаете и почему?

[kkirsanov.livejournal.com]

--Я правильно понимаю, что эквивалентность лямбда исчисления и машины Тьюринга для вас пустой звук?
Неправильно.

--Про костыли интересен более полный ответ - что вы ими считаете и почему?
Деалю системы управления для мобильных роботов.
Ради интереса попробовал на хаскеле.
Получилась куча монад и почти императивно.

[kurilka.livejournal.com]

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

[metaclass.livejournal.com]

Кстати, насчет эквивалентности. Я не очень понимаю операционную семантику лямбда-исчисления. Если построить машину Тьюринга в железе и запрограмировать примерно понятно как, то как построить считалку на лямбдах - не очень :)

[kurilka.livejournal.com]

Как варианты - http://en.wikipedia.org/wiki/SECD http://en.wikipedia.org/wiki/Categorical_abstract_machine (оно же CAM из CAML), в хаскеле вроде G-machine (пока руки не дошли толком разобраться, у Simon Peyton Jones в книжках разбирается вроде как), у клина - ABC-machine, http://www.st.cs.ru.nl/papers/1993/plaseek93/Ch10.ABC.ps
По сути там переписывание графов, хотя не сказал бы что хорошо разбираюсь в теме.

[gds.livejournal.com]

а если передам?

[metaclass.livejournal.com]

Да совместимо оно, только что состояния в монадах таскаются.

[dmzlj.livejournal.com]

Да не факт что должно что-то вообще таскаться в монадах - зависит от конкретной ситуации. То, что fsm и ФП несовместимы - это просто какая-то глупость, в общем случае.

[kurilka.livejournal.com]

не обязательно в монадах, можно и явной передачей (см. Erlang/Clean)

[metaclass.livejournal.com]

Явная передача это реализация монад вручную в итоге получится.

[kurilka.livejournal.com]

Я бы сказал наоборот - невыделение монад в отдельную сущность, в отличие от хаскеля где есть шанс отделить мух от котлет.

[dmzlj.livejournal.com]

Это какие-то неправильные умные книжки. Или вы их как-то неправильно поняли. Вот, например, конечный автомат на два состояния - Пыщь и Адын:

open ExtString

type state = Pysh | Adyn 

let fsm evt =
    let input state x = match state, x with
    | Pysh, '{' -> Adyn
    | Pysh, ' ' -> Pysh 
    | Pysh, c   -> Printf.printf "Pysh! %c\n" c; Pysh
    | Adyn, '}' -> Pysh
    | Adyn, ' ' -> Adyn
    | Adyn, c   -> Printf.printf "Adyn! %c\n" c; Adyn 

    in List.fold_left input Pysh (String.explode evt)

let _ = 
    fsm "000000000 { 1111111111111111111 } 2222222222222222222"

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

заметим еще, что сделать такой автомат на императивном языке "где есть состояния" c++ - будет несколько более громоздко.

[kkirsanov.livejournal.com]

--Или вы их как-то неправильно поняли.
Всякое бывает

[kkirsanov.livejournal.com]

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

[dmzlj.livejournal.com]

Ну, это был окамл, но для хаскелла могу порекомендовать сайты

http://learnyouahaskell.com/ и http://book.realworldhaskell.org/read/

не то, что бы там были типичные задачи, но какие-то задачи в процессе изучения языка разбираются.


По поводу задач лично мне понравился курс вот этого вот товарища: http://andrej.com/plzoo/
по написанию трансляторов языков. Много маленьких примеров имплементация языков программирования на ocaml

[nine_k]

Лет 10 назад мне доводилось как раз делать гирлянды окон с формами, традиционный "толстый клиент" такой. Очень тянуло написать state machine для всего этого, просится же.

Но не написал. Потому что, как посмотришь, так выходит, что граф состояний довольно сильно связен, все ветки описывать прямолинейно — некомпактно выходит, описывать "в общем виде" — приходим примерно к тому, от чего ушли. А уж если втащить туда влияние всяких опций (то показывать, это не показывать, вон то работает в зависимости от настроек), то и вообще граф расползается ужасно. В результате остановился на кусочках state machine (переход между состояниями делает enable-disable наборам команд, как в turbovision) и описанию логики "в свободной форме" в остальном.

Потом я перелез на веб-интерфейсы. А там вообще практически полносвязный граф: юзер может и url любой из закладок достать, и кнопки back и forward понажимать. Там как-то проще с концепцией состояния сессии.

В общем, КА как язык описания хорош для протоколов связи и, пожалуй, "узких" UI, типа кассового аппарата. А для "обычных" UI — сомневаюсь.

Для UI, в особенности web, мне кажется более интересным использование continuations (seaside, weblocks, wee, etc). Там, как мне кажется (я не пробовал, только читал описания) код действительно получается более компактным и прямолинейным. Какие там подводные камни, не знаю.