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

[metaclass]

haskell datagrid

ocaml datagrid

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

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

Comments

[nine_k]

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

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

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

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

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