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

[metaclass]

haskell datagrid

ocaml datagrid

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

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

Comments

[dmzlj.livejournal.com]

Как обычно - через FFI.

[metaclass.livejournal.com]

Через FFI в хаскеле становятся доступными элементы GUI. Дальше - ручная сборка GUI в коде, хотя может даже и ui файлы можно грузить. Но это банально ничего не решает - то же самое у нас и в дельфи есть, только без сношения стоя в гамаке.
Есть, конечно, экспериментальные образцы правильного функционального GUI, но там такой академический трэш, что без явной надобности до продакшена его никто не доведет тоже.

[metaclass.livejournal.com]

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

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

[metaclass.livejournal.com]

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

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

[kkirsanov.livejournal.com]

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

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

[kurilka.livejournal.com]

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

[gds.livejournal.com]

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

[gds.livejournal.com]

кстати, я заметил одно очень важное наблюдение. Как оказывается не только казалось, но языки функционального функционального программирования разрабатываются под линуксами и прочим юниксом. И не человеком, но профессорами! Надеюсь, отсюда из этого их качевство вполне очевидно и не может потакать современными методиками разработки программируемого обеспечевния.

[kkirsanov.livejournal.com]

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

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

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

[kurilka.livejournal.com]

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

[kkirsanov.livejournal.com]

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

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

[kurilka.livejournal.com]

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

[metaclass.livejournal.com]

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

[metaclass.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++ - будет несколько более громоздко.

[dmzlj.livejournal.com]

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

[lupus-lupusum.livejournal.com]

через сокеты

[metaclass.livejournal.com]

И получим полный набор геморроя, когда одмины поставят на винду новый суперфайрволл, который мало того, что прикроет порты, так и не даст нашей проге запустить вторую, которая работает с сетью. Или набор геморроя при деплойменте и саппорте, когда нужно будет вместо одной проги проверять на работоспособность две и больше.
Юникс сокетов на винде как бы и нету, а всякие там именнованные пайпы это тоже то еще развлечение.
В общем, как я уже писал - сначала мы создаем себе проблемы, потом героически их преодолеваем. Это классическая ситуация, когда цель - не деньги заработать, а развлечься и почесать мозги за счет работы. Все эти "сетевые" приложения, "сервисы", "модульная архитектура" - это же в 90% случаев фетиш и костыли, на самом деле, а не реальная производственная надобность.

[lupus-lupusum.livejournal.com]

тут геморрой предсказуемый, а потому и не опасный. и тестируется открытый сокет программы легко.

еще есть OLE automation, но то для ценителей.

[metaclass.livejournal.com]

О да, если что и хуже связи через сокеты, так это завязываться на регистрацию 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
По сути там переписывание графов, хотя не сказал бы что хорошо разбираюсь в теме.

[metaclass.livejournal.com]

Про G-машину я у SPJ читал, но только самую краткую часть, где они описывают, как это все прикручивают к обычному железу. А основные длинные книги осилить никак не могу - с экрана тяжело читать.
Но тут проблема в другом. Машина тьюринга от современных процов и языков программирования отличается очень сильно, хотя я примерно представляю, как можно ее преобразовать до проца с простейшим набором действий.
А вот для лямбда-исчисления я затрудняюсь такую же последовательность представить, а во всех практических реализациях ФП используют уже готовые команды существующих процессоров или языков низкого уровня на которых это реализовано. Т.е. формально, операцию сложения можно описать в нумералах черча, но никто ж этого делать практически не станет, а вместо этого используют операции от обычных процессоров, которые сами по себе ближе к тьюрингу, чем к лямбдам.

[kurilka.livejournal.com]

С чего это оно ближе к тьюрингу?
Как раз там есть лишь лента и таблица переходов, в отличие от ФП с лямбдами где ты можешь свободно заменять эквивалентные функции. Интересно было бы узнать, где в машине Тьюринга есть композиция/абстракция.

[kurilka.livejournal.com]

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

[metaclass.livejournal.com]

Ближе к тьюрингу - это я про процы классические. Там как раз лента(память) и таблица переходов(проц с его поведением).
Кстати, я сейчас почитал про SECD - там жеж тоже самое - список команд, и списки-регистры. По мне, так это тоже ближе к тьюрингу, чем к лямбда-исчислению, хотя там и добавлены операции конструирования и применения функций.