Прозрачность по ссылкам и пользовательский интефейс.

May 18, 2007 15:38

Я факультативно взялся освежить знания насчет Fudgets и параллельно поспорил с potan насчет построения пользовательских интерфейсов ( Read more... )

ссылочная прозрачность, Эрланг, fudgets, языки программирования, пользовательские интерфейсы, Хаскель

Leave a comment

Comments 78

bacek May 18 2007, 12:20:36 UTC
А можно пару вопросов?

1. Где почитать по-подробнее про фуджеты?
2. В WPF _очень_ качественно разнесли логику, данные и управление (ИМХО конечно. Во всяком случае это лучшее технологическое решение от Майкрософта, которое я видел)

Reply

thesz May 18 2007, 12:29:00 UTC
http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/
http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/

Какая-то из них может оказаться лучше. ;)

А кто такие WPF?

Reply

bacek May 18 2007, 13:18:43 UTC
За ссылки спасибо. Завтра почитаю.

А WPF -- Windows Presentation Foundation. То, на чём Виста делалась. Ключевые слова Avalon, XAML. Они (наконец-то) разделили визуальное представление контрола, "бизнес"-логику этого контрола и взаимодействие между ними. Если бы там ещё столько багов не было...

Reply

thesz May 18 2007, 14:37:10 UTC
Баги, кстати, от внутренней непрозрачности, по-моему. ;)

Reply


subdmitry May 18 2007, 23:04:26 UTC
Для решения второй проблемы (композиции логики) было бы неплохо иметь доступ к состоянию контролов как к именованным переменным. А то получается, что элементарная задача увеличения значения счетчика на единицу при нажатии на кнопку в функциональном подходе уже требует делать нетривиальные развязки на функциях. И счетчик это еще ерунда. Любая более-менее серьезная программа не обходится без диалога с опциями, которых запросто может быть и несколько десятков. Если к ним нельзя получить доступ как к переменным, то как его реализовывать в функциональном стиле? Это вообще возможно? Сильно подозреваю, что даже если и возможно, то развязка там получиться такая, что в ней черт ногу сломит.

Reply

thesz May 19 2007, 00:08:41 UTC
1) А ты смотрел на фуджеты-то? Попробуй сделать калькулятор короче и изящней. Чуть выше была дана ссылка.
2) "Состояние контролов, как именованые переменные" - это ссылки, грубо говоря. То есть то, что мешает композиции. Отвергаем.
3) Да, придется коммутировать потоки. Это несложно, хотя и нудно. Можно и комбинаторов придумать.

Reply

subdmitry May 19 2007, 21:15:40 UTC
1. Да, я посмотрел на фуджеты и под их впечатлением пишу. Впечатление такое, что для решения даже элементарных проблем там надо напрягаться. Вот уже достаточно простая задача - написать увеличение значения счетчика.

counterF = intDispF >==< mapstateF count 0 >==< buttonF "Up ( ... )

Reply

thesz May 19 2007, 22:06:29 UTC
1. Ты сравниваешь построение элемента и его логику с одной только логикой (да и то - только ее частью).

Поэтому усложнение на ровном месте.

BTW, написание преобразующих состояние функций (i -> st -> (o,st)) проще, чем написание изменения глобального состояния. Это мой личный опыт (моделируя аппаратуру на C++, я пришел к такому же стилю программирования) и опыт товарищей из Эрланга.

Визуальные средства не дают декларативности. Вместо диалога, подходящего под look-n-feel текущей операционки мы полчаем именно кнопочки и именно "вот такую вот иконку."

2.Data.IORef

Им мало, кто пользуется. Только по необходимости.

3.Это хорошо, когда у тебя одна форма. Теперь представь, что одна и та же форма используется в паре-тройке мест, в других разных формах. Уже станет менее удобно.

И там далее сложность все увеличивается.

Протаскивание конфигурации накладно, но полезно. Видно, кто этим пользуется.

Если очень охота - state monad. Функционально и протаскивание скрыто.

Reply


gdy May 19 2007, 16:01:35 UTC
И как будет выглядеть программа, которая показывает два поля ввода для чисел и два поля, которые показывают сумму и разность чисел в полях ввода?

Reply

gdy May 19 2007, 16:05:00 UTC
На fudgets я смотрел пару минут, но у тебя, я вижу, есть свободное время ;-)

Reply

thesz May 19 2007, 16:09:32 UTC
Это нечестно - пользоваться чужим свободным временем. Тем более, что у меня его, чтой-то, нет. ;)

Reply

gdy May 20 2007, 10:42:25 UTC
Решительно отвергаю твоё обвинение в нечестности :-)

Reply


onrue May 30 2007, 22:30:54 UTC
А разве они живы вообще? С практической стороны - уродливая лицензия, кривость сборки…

Всем красивы в общем, но как пишут в “Genuinely Functional GUIs”:
The closest relative to our work is Fudgets. Fudgets are implemented as stream processors, where each Fudget has high level and low level input and output streams. The high-level streams in Fudgets serve a role similar to the auxiliary semantic signals in our GUI type. The programming interface to Fudgets is very similar to that of Fruit, although Fudgets is based on discrete, asynchronous streams, whereas Fruit is based on continuous, synchronous signals ( ... )

Reply

thesz May 31 2007, 10:17:53 UTC
Since we have not seen a formal definition of X windows, it is not clear to us what the denotational model of a Fudget is, beyond saying that it is a stream processor that emits and consumes X protocol requests.

Это неправда.

Для фуджетов давно (1996, по-моему) разработана их теория - модифицированное пи-исчисление. К X Window System это имеет очень далекое отношение.

Grapefruit... Он, похоже, построен на идеях Fran.

Мне больше идеи фуджетов нравятся. ;)

Reply


Leave a comment

Up