Прозрачность по ссылкам и пользовательский интефейс.
Я факультативно взялся освежить знания насчет Fudgets и параллельно поспорил с potan насчет построения пользовательских интерфейсов.
Проблем с пользовательскими интерфейсами у нас две - композиция расположения элементов управления на экране и композиция логики. Они решаются отдельно друг от друга и первая значительно легче второй.
Для второй, по-хорошему, необходима ссылочная прозрачность элементов управления. Чтобы мы могли сделать счетчик и встраивать его куда угодно. А потом легким движением руки сделать ограниченный счетчик и встраивать его в те же места. И чтобы мы могли легким движением руки сделать несколько копий этого счетчика.
В тех же самых фуджетах элемент пользовательского интерфейса - это преобразователь потока сообщений. Он не содержит ссылок на какие-то отображаемые элементы, не будучи никуда подсоединен.
Только после подсоединения и размещения он начинает быть с чем-то связан. До этого - это обычное значение языка Хаскель, его можно использовать столько раз, сколько необходимо, комбинируя так, как это необходимо.
Поэтому построение элементов управления получается полностью декларативным и прозрачным по ссылкам.
В языке Tcl, в его неотъемлемой части под названием Tk, размещение элементов управления решена практически идеально. А вот композиция логики в чистом Tcl/Tk отсутствует, как класс. Для композиции логики могут использоваться не очень понятные обвязки наподобие BWidgets - очень и очень толстые (хотя и удобные в использовании уже готовых вещей).
В известных мне экранных библиотеках для C++ с размещением элементов на экране тоже все в порядке (уже довольно давно, лет семь или восемь, как). С композицией логики - беда. Практически везде изменение поведения реализуется через наследование, заставляя программиста, во-первых, планировать иерархию наследования и, во-вторых, усложняя динамическое изменения отображения.
И в случае Tcl/Tk, и в случае C++ (наверное, то же самое относится ко многим другим языкам) еще до размещения элемента управления на экране нам необходимо создать соответствующий ему "объект." Ссылку на него. Мы не можем просто "скопировать" однажды сконструированый объект в другое выражение. Это, в принципе, тоже не облегчает жизнь.
По-моему, к Эрлангу это тоже применимо.
Процессы в Эрланге обладают именем, "идентичностью." Их надо создавать и убивать сознательно. Поэтому для "серъезной" работы по созданию логики пользовательских интерфейсов чистый Эрланг не очень применим. Для него будет необходимо создать библиотеку а-ля те же Fudgets. А Fudgets используют ленивые вычисления. ;)
Проблем с пользовательскими интерфейсами у нас две - композиция расположения элементов управления на экране и композиция логики. Они решаются отдельно друг от друга и первая значительно легче второй.
Для второй, по-хорошему, необходима ссылочная прозрачность элементов управления. Чтобы мы могли сделать счетчик и встраивать его куда угодно. А потом легким движением руки сделать ограниченный счетчик и встраивать его в те же места. И чтобы мы могли легким движением руки сделать несколько копий этого счетчика.
В тех же самых фуджетах элемент пользовательского интерфейса - это преобразователь потока сообщений. Он не содержит ссылок на какие-то отображаемые элементы, не будучи никуда подсоединен.
Только после подсоединения и размещения он начинает быть с чем-то связан. До этого - это обычное значение языка Хаскель, его можно использовать столько раз, сколько необходимо, комбинируя так, как это необходимо.
Поэтому построение элементов управления получается полностью декларативным и прозрачным по ссылкам.
В языке Tcl, в его неотъемлемой части под названием Tk, размещение элементов управления решена практически идеально. А вот композиция логики в чистом Tcl/Tk отсутствует, как класс. Для композиции логики могут использоваться не очень понятные обвязки наподобие BWidgets - очень и очень толстые (хотя и удобные в использовании уже готовых вещей).
В известных мне экранных библиотеках для C++ с размещением элементов на экране тоже все в порядке (уже довольно давно, лет семь или восемь, как). С композицией логики - беда. Практически везде изменение поведения реализуется через наследование, заставляя программиста, во-первых, планировать иерархию наследования и, во-вторых, усложняя динамическое изменения отображения.
И в случае Tcl/Tk, и в случае C++ (наверное, то же самое относится ко многим другим языкам) еще до размещения элемента управления на экране нам необходимо создать соответствующий ему "объект." Ссылку на него. Мы не можем просто "скопировать" однажды сконструированый объект в другое выражение. Это, в принципе, тоже не облегчает жизнь.
По-моему, к Эрлангу это тоже применимо.
Процессы в Эрланге обладают именем, "идентичностью." Их надо создавать и убивать сознательно. Поэтому для "серъезной" работы по созданию логики пользовательских интерфейсов чистый Эрланг не очень применим. Для него будет необходимо создать библиотеку а-ля те же Fudgets. А Fudgets используют ленивые вычисления. ;)