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

[metaclass]

haskell datagrid

ocaml datagrid

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

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

Comments

[dizel-by.livejournal.com]

А что, разве нельзя открыть окно с контейнером какого-нибудь Gecko или webkit, нарисовать в нём HTML-форму и работать с ней как с DOM?

[metaclass.livejournal.com]

Ебаный кошмар. Как же вы заебали своим вебом, простите меня.
Можно, конечно. Еще можно переписать вручную все нужные компоненты на низкоуровневых примитивах, или написать биндинги к QT, или делать back-end логику на ФП, а морду на обычных языках.
Просто тогда акценты смещаются с "написания софта для клиентов как можно быстрее" на "героические разборки с проблемами созданными самим себе". Т.е. сначала мы учимся подключать веб-движок в софт, затем изучаем как сделать настолько же rich-gui на вебе, потом воюем с его ограничениями, итд. Или там "изучаем как срастить хаскель, клиентскую либу СУБД, гуй на дельфи или там .NEТ и генератор отчетов на вши красной, желтой, гусеницах, etc"

Суть такая: я могу на дельфи или там на .NEТ +SQL +генератор отчетов быстро клепать db-centric софт. Очень быстро. Но некоторые вещи на них делать просто задалбывает, и в случае сложных расчетов это все становится малочитабельно и неподдерживаемо. ФП языки с их выводом типов, функциями высшего порядка, каррингом и метапрограммированием могли бы это дело сильно упростить. Но: у них нет UI. Тупо нет. То, что адепты говорят "есть" - это хрень. Это из разряда как у ребе белнетмон писали что датчики груза для белаза "есть". Это "есть" еще два-три месяца изучать, прикручивать и напильником подгонять придется. А за это время я все свои задачи три раза обычными индусскими методами решу.

[dmzlj.livejournal.com]

ну есть же wx. там есть гриды. к базе забиндить придется вручную. и вообще можно склепать веб-морду на каком-нибудь рич-гуи-фреймворке.

не?

[metaclass.livejournal.com]

Ну, на будущее я напряг девелопера делать рич-гуи-фреймворк на вебе, он все равно нужен.
Но для некоторых вещей нативный не-веб GUI - безальтернативен, имхо. Т.е., да, можно там навернуть аякса всякого, можно сделать почти так же быстро реагирующим на юзеровские действия, но это ровно до тех пор, пока не окажется, что к программе нужно прикрутить электронные весы на RS232 порту, или там блютуз-адаптер, или rfid-читалку. И даже без этого - если мы имеем классический GUI и на нем задача решается за один день рисованием в дизайнере, а вместо этого предлагается извращаться с вебом, добиваясь такой же эффективности - неясно зачем это тогда нужно:)

[dizel-by.livejournal.com]

wx не имеет права на жизнь

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

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

[dmzlj.livejournal.com]

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

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

[alexott.livejournal.com]

http://haskell.org/gtk2hs/archives/category/screenshots/ - не?

[alexott.livejournal.com]

ну прямого датагрида нету, но мне кажется не так уж тяжело и соорудить...

[dmzlj.livejournal.com]

там все еще осложняется тем, что винды людям до сих пор нужны.

[fantaseour.livejournal.com]

Как же я Вас понимаю.... ууууу....

[permea-kra.livejournal.com]

Ребе, а как вы относитесь к идее разнести логику и гуй по двум разным языкам?

[vp.livejournal.com]

А сращивание одного с другим будет выглядеть каким образом?
Ключевой момент.

[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 мне и в других языках хватает :)

[dmzlj.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[vp.livejournal.com]

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

[dmzlj.livejournal.com]

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

[metaclass.livejournal.com]

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

[vp.livejournal.com]

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

[aamonster.livejournal.com]

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

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

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

[kurilka.livejournal.com]

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

[gds.livejournal.com]

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

[https://services.mozilla.com/openid/belpartizan (from livejournal.com)]

Да, большая часть ФП действительно писальась в университетах. Однако тот же Erlang писался Ericsson. А такого качества, как у него фиг добьёшься на императивных языках: простой системы не более 3 часов за 50 лет.

А про то, что ФП не подходят под современные методики разработки, можно поподробнее?

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