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

[metaclass]

haskell datagrid

ocaml datagrid

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

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

Comments

[metaclass.livejournal.com]

Как к вынужденной мере, которую придется использовать, скорее всего.
На данный момент, что GUI, что FFI в ФП выглядят одинаково ужасно, так что неясно, что лучше делать - разбираться с родными биндингами к GUI тулкитам, или же разбираться с FFI и прикручивать хаскелевые модули в виде DLL к проге на чем-нибудь более приземленном.
В общем-то FFI сильно обессмысливает использование хаскеля - что толку от сжатого представления алгоритма на хаскеле, если для этого нужна обвязка для доступа к БД и передачи данных в GUI, которая по размеру больше самого алгоритма, сделанного в лоб обычным образом. Причем, если по хорошему, доступ к БД должен быть интегрирован с выводом типов, а то описаний таблиц в виде Map

[Error: Irreparable invalid markup ('<fieldname,value>') in entry. Owner must fix manually. Raw contents below.]

Как к вынужденной мере, которую придется использовать, скорее всего.
На данный момент, что GUI, что FFI в ФП выглядят одинаково ужасно, так что неясно, что лучше делать - разбираться с родными биндингами к GUI тулкитам, или же разбираться с FFI и прикручивать хаскелевые модули в виде DLL к проге на чем-нибудь более приземленном.
В общем-то FFI сильно обессмысливает использование хаскеля - что толку от сжатого представления алгоритма на хаскеле, если для этого нужна обвязка для доступа к БД и передачи данных в GUI, которая по размеру больше самого алгоритма, сделанного в лоб обычным образом. Причем, если по хорошему, доступ к БД должен быть интегрирован с выводом типов, а то описаний таблиц в виде Map<FieldName,Value> и FieldByName['SHOPETO_ID'].AsDatetime мне и в других языках хватает :)

[blacklion.livejournal.com]

ну на безрыбье и жопа соловей, знаете ли.
Вот только господин Метакласс хочент удобно и красиво, а не как придётся -- вон, он 2 недели на вылизывание тратит. Думаю, не зря.

[dmzlj.livejournal.com]

вскрытие покажет

[permea-kra.livejournal.com]

Биндинги к субд в хаскеле есть. Довольно лаконичные, имхо. Фреймворк для интеграции с выводом типов тоже есть, но он, пока, скорее proof of concept, и нуждается в расширении (не весь зоопарк родных типов SQL поддерживается). Впрочем, посмотреть на него можно.

Я ещё подумал бы над разнесением кода двух языков по разным процессам или ниткам. A ffi в хаскеле ужасен, да, но и тульзы для его автогенерации есть. Хотя они тоже неидеальны.

[permea-kra.livejournal.com]

Хороший вопрос, на самом деле. Возможно, IPC чем-то текст-ориентированным? FFI больно страшен, да и всё равно желательно выделять отдельный working thread, чтобы гуй не подвешивать.

[metaclass.livejournal.com]

Насчет разных процессов я думал, все таки общаться между софтом через хотя бы текстовый stdin/stdout хотя и медленно и безумно, но как минимум, пригодно для того, чтобы с обоих сторон вывести автоматом код сериализации/десериализации объектов.

[zamotivator.livejournal.com]

А может просто взять и попробовать?
datagrid я как понял это такой rocket science в твоих задачах.
Сделай один раз - твоя работе не пропадет, как минимум поймёшь что же мешает.

И опять же, что мешает логику хреначить на одном языке, а GUI просто биндить?
Поневоле доекмопозицию сделаешь + повторная используемость кода вырастет

[zamotivator.livejournal.com]

D-BUS/(C)ORB(A)?

[zamotivator.livejournal.com]

Я, кстати, поглядел как биндинги в ocaml делаются.
Впечатлился. Как в Си (никаких заморочек).
На тему маршализации да, курить но.
НО языки типа Ocaml/Haskell - это мета языки. Вполне за пару дней можно сваять генератор биндингов в dll.

[metaclass.livejournal.com]

Оно как бы не совсем rocket science. Я на основе стандартных дельфийских гридов уже понаписывал всяческой нетривиальщины - уж очень хорошо они спроектированы изначально, в отличие от того же дотнета.
Но есть психологический барьер: стоит только начать писать для себя инструменты, вместо решения конкретных задач существующими инструментами, и сразу вырастут красные глаза, а ребе белнетмон будет за спиной показывать пальцем и называть абстракционистом :)
Т.е. в среде разработчиков софта типа нашего, написание новых инструментов считается табу, признаком теоретика и неумения/нежелания пользоваться готовыми инструментами.
Но таки ситуация с готовыми инструментами бесит уже давно, их не хватает/неюзабельно, даже в том, случае когда казалось бы все сделано чтобы было хорошо, как в .NET-е.

[metaclass.livejournal.com]

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

[zamotivator.livejournal.com]

Спольски хорошо писал.
Либо выбирайте хорошие инструменты, либо (если их нет) напишите сами, чтобы минимизировать риски (смерть инструмента, и так далее).
В частности для разработки Екселя они написали свой компилятор Си (я ржал когда узнал), и он пояснял чем это хорошо - переносимый между PowerPC и x86 p-код, а значит эксель портируем и туда и туда (прочитав это я перестал ржать)

[zamotivator.livejournal.com]

Посмотрите как дружат ocaml с erlang'ом.

[x-a-e-p.livejournal.com]

вот только не надо про wx. это тотальный неиллюзорный пиздец по всем статьям

[x-a-e-p.livejournal.com]

это я к тому, что на более-менее серьёзных задачах там приходится переизобретать плюсы заново, да и впридачу решать задачи типа 'как обмануть wx-макросы, чтобы сделать множественное наследование'

[dmzlj.livejournal.com]

Ну ладно, черт с ним с wx-ом. Но вот есть Qt и qtHaskell. Это тоже не GUI ? О Qt отзываются хорошо. Если Qt это тоже "не GUI" - то думаю, можно зафиксировать мнение, что GUI для ФП нет.

Хотя лично я не очень даже верю в тот негатив, который тут пишут про wx - думаю, это некое преувеличение ужасов.

[dmzlj.livejournal.com]

я смотрел wxHaskell и никакого пиздеца там не вижу. навскидку, оно выглядит лучше, чем qtHaskell. относительно сложные примеры с гридами в wxHaskell тоже есть. сложные GUI приложения на wx написать можно и пишут.

"переизобретать плюсы" точно не придется. можно привести пример пиздеца?

[dmzlj.livejournal.com]

Итого, для хаскелла есть wx, qt, gtk и fltk. То есть забиндено все, что вообще бывает опенсорсного. Если упомянутые средства не катят, то что тогда вообще понимается под GUI? Что должно быть, что бы можно было сказать, что GUI есть?

[metaclass.livejournal.com]

Qt это на данный момент наиболее адекватное из всего что есть. Но там вроде бы качество тоже далеко от продакшена.

[metaclass.livejournal.com]

Биндинги это хорошо.
Вот я сейчас потратил час только на то чтобы поставить wxHaskell и заставить собираться примеры идущие с ним. Это с учетом того, что я это уже один раз делал и примерно помню, что и где надо подкрутить, чтобы оно поставилось, и как проверить что оно ставится, и как билдить проги ghc с дополнительными пакетами.
И после всего этого примеры, в частности, Grid.hs падает с AV при попытке навести на него мышь.
Пример с дбгридом таки запустился. Доступ к БД: только odbc. Только чтение, редактирования нет. Элемент UI, выдаваемый за dbgrid - listview.
Если я попытаюсь такое использовать для работы - это откат на 10 лет назад по качеству. Для заявлений "GUI есть" и показа скриншотов - подходит. Для работы - нет.
Остальные биндинги, подозреваю, не лучше. Просто никому не нужно их развивать для того, чтобы их можно было использовать в нормальной работе, а не для коротких proof-of-concept прог.

[aamonster.livejournal.com]

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

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

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

[kurilka.livejournal.com]

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

[vp.livejournal.com]

Я закончу мысль. Потому, что мало кто из народа завязан на ИТ индустрию "от и до". То есть человеку может быть интересно программировать на хаскеле, но он далек от продакшына, и вообще далек от сейла, а вопросы интеграции и поставки системы в целом ему даже в моск не заходили. Вот от этого вся и проблема.
Мучаются те, кто видит реальные задачи целиком и относится к этому не как к фатишу, а как к ИНСТРУМЕНТУ, который должен уменьшать трудозатраты, а не увеличивать.
Тот же самый QT приснопомянутый. Я на него посмотрел только тогда, когда мне было обещано, что я буду избавлен от шапито в виде настройки отдельно редактора + отдельно мейка и т.п. Я не люблю шапито!! Я хочу просто работать и получать за это вознаграждение.

[vp.livejournal.com]

Что я не сильно понимаю. QT - это набор C++ расширений и библиотек. Как производится интеграция с хаскелем?

[aamonster.livejournal.com]

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