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

[metaclass]

haskell datagrid

ocaml datagrid

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

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

Comments

[metaclass.livejournal.com]

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

[kurilka.livejournal.com]

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

[kurilka.livejournal.com]

Ближе-дальше - какие-то неконкретные категории. На железе реализуется? Реализуется. Лямбды позволяет выполнять? Позволяет.
Что ещё собственно требуется?

[olegy.livejournal.com]

Когда то был проект, назывался jazz - клиент на QT, сервер на питоне, обмен через сокеты xml ем типа тег <window x ="11" y="111"/><button и т.п.

[kkirsanov.livejournal.com]

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

[kkirsanov.livejournal.com]

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

[dmzlj.livejournal.com]

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

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

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


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

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

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

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

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

[ledernierheros.livejournal.com]

А почему нельзя было уже существующий компилятор, умеющий эти платформы использовать?

[zamotivator.livejournal.com]

Видимо, временем, когда Спольски там работал. Врать не хочу, поищите сами.
Один из первых офисов был, вроде как.

[zamotivator.livejournal.com]

В случае ML, Haskell, Lisp, такую генерацию сделать на порядки проще чем из С или С++, к примеру.
Автоматизировать полностью можно, моё ИМХО

[metaclass.livejournal.com]

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

[thedeemon.livejournal.com]

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

F# уже изобрели. Там и привычные богатые WinForms, и ФПшные вывод типов, ФВП, карринг и пр.

Для Окамла по идее есть CSML, который позволяет WinForms заюзать опять же.
http://www.lexifi.com/csml/

[nine_k]

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

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

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

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

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

[(Anonymous)]

А с другой стороны кто вам обещал что Ocaml нацелен на db-centric приложения? :) Наоборот даже, у него четко очерченная ниша. Есть масса языков, на которых также крайне сложно писать db-centric приложения и которые при этом остаются непревзойденными в своих нишах. Список их поистине огромен и среди них есть языки-парадигмы аж! :)

Берите Дельфи или MS Access или PowerBuilder и тп, они ведь только для этого и были созданы.