1. Да, я посмотрел на фуджеты и под их впечатлением пишу. Впечатление такое, что для решения даже элементарных проблем там надо напрягаться. Вот уже достаточно простая задача - написать увеличение значения счетчика.
Налицо качественное усложнение программы, причем на ровном месте.
Калькулятор там тоже очень сложный для понимания. Откровенно говоря, не думаю, что многие из местных хаскельных программистов смогут такое воспроизвести без заглядывания в тот исходик. Между тем, в визуальных средствах калькулятор делается вообще без какого-либо напряжения сознания.
2. Понятно что отвергаем, ведь в Хаскелле выбора-то нет - там можно писать только функционально, такую императивность он не поддерживает. Между тем, ввели бы там мутабельные переменные как в ML, мощность языка от этого только возросла бы.
3. Вообще-то в императивном подходе сделать редактирование каких-то значений, лежащих в глобальных переменных очень просто - надо всего два оператора на каждое значение - один копирует значение глобальной переменной в контрол при создании формы, второй - копирует назад при закрытии формы. И никаких ненужных наворотов.
Да, и использовать конфиг в императивном подходе тоже проще - глобальные переменные доступны в любом месте программы, а в функциональном варианте надо этот конфиг передавать как параметр во все места, где он может понадобиться (а на практике таких мест может быть очень много). Налицо преимущество и в этом вопросе императивного программирования.
1. Ты сравниваешь построение элемента и его логику с одной только логикой (да и то - только ее частью).
Поэтому усложнение на ровном месте.
BTW, написание преобразующих состояние функций (i -> st -> (o,st)) проще, чем написание изменения глобального состояния. Это мой личный опыт (моделируя аппаратуру на C++, я пришел к такому же стилю программирования) и опыт товарищей из Эрланга.
Визуальные средства не дают декларативности. Вместо диалога, подходящего под look-n-feel текущей операционки мы полчаем именно кнопочки и именно "вот такую вот иконку."
2.Data.IORef
Им мало, кто пользуется. Только по необходимости.
3.Это хорошо, когда у тебя одна форма. Теперь представь, что одна и та же форма используется в паре-тройке мест, в других разных формах. Уже станет менее удобно.
И там далее сложность все увеличивается.
Протаскивание конфигурации накладно, но полезно. Видно, кто этим пользуется.
Если очень охота - state monad. Функционально и протаскивание скрыто.
1. На мой взгляд, даже если выделить оттуда одну логику, все равно уже несколько сложнее.
Мне, кстати, не нравиться, что логика там свалена в одну кучу с инициализацией. А если надо что-то в свойствах контрола поменять, фонт, допустим, это тоже пойдет в эту кучу? Это же такое нагромождение получиться. Намного удобнее, когда можно получить доступ ко всем пропертям и обрабатываемым эвентам контрола через специальное окошко, как это сделано в BCB/Дельфи.
Визуальные средства как правило вообще непереносимые (компилируют только под одну платформу). Это, конечно, недостаток. С другой стороны, зато они позволяют (в отличие от самовыравнивающихся контролов) делать всякие дизайнерские изыски и прочие радости ручной настройки. Вот понадобиться, допустим, в калькуляторе выводить надцать знаков числа и вдруг окажется, что имеющегося размера поля для этого не хватает т.е. его надо увеличивать. Как это сделать в самонастраивающейся программе, если при этом заодно требуется для красоты изменить и размеры всех кнопочек, чтобы матрица с ними была такой же ширины?
2. Ага, значит таки есть. Рад за Хаскель. Правда до меня постепенно доходит, что в ленивом языке пользоваться такой штукой можно только поотключав эту ленивость нафиг, иначе могут начаться глюки. Поэтому наверное и мало пользуются.
3. Вообще-то речь изначально была о редактировании опций программы, для этого глобальные переменные отлично подходят. Но в принципе привязать такое окно к редактированию какого-то объекта, заданного ссылкой, не так уж и сложно.
Насчет state monad я не очень понимаю. А разве не надо ее задавать в описании типа функции (для чего тоже надо возиться)? Разве использование монады может быть полностью выведено автоматически?
Кстати, как тебе понравилось мнение того дяди, который сказал, что неописывать типизацию функций в Хаскеле чревато тем, что он начинат выдавать сообщения об ошибках в местах, находящихся весьма далеко от реального места ошибки? Ты с таким сталкиваешься?
Дизайнер должен сказать, что "вот здесь вот такие ограничения, а вот в этой форме поддерживать соотношение сторон самой формы и вот этих кнопочек внутри близким к золотому сечению, и чтобы шрифт кнопок масштабировался соответственно, а вот в этой форме все совсем по другому, там надо..." Или даже так: "Все формы и подформы должны иметь соотношение сторон, близкое к золотому сечению, все формы сопровождаются указанием важности элементов, элементы с одинаковой важностью должны располагаться в ряд или столбец."
Дело программиста - запрограммировать все эти ограничения. И, кстати, вытянуть их из дизайнера. ;)
Максимум, что от дизайнера требуется сделать вручную - это примерно показать расположение элементов формы.
2. С ленивыми вычислениями справляется IO. Почему они и называются IORef.
3. Использование монады будет выведено автоматически.
Глобальные переменные "опции программы" - это очень и очень частный случай. Редко встречающийся. Интереснее рассмотреть случай пообщее.
Мнение какого дяди?
Да, кстати, я с этим сегодня столкнулся. Функция в другом, недавно модифицированном, но еще не отлаженном модуле начала принимать списки [a] вместо просто a. Пришлось потратить около десяти минут, чтобы это исправить. Забыл в одном месте concatMap.
1. В логику еще входит занание интерфейса функции mapstateF, которая обладает своими гитиками (например, зачем там возвращать cписок [n+1] и что он означает?) Ну ладно, изменение значения поля еще более-менее ничего проработано, а вот его получение? Человек тут тебя спросил насчет двух полей и их суммы и разности. Как результат тебе пришлось задуматься и начать что-то изобретать. А ведь любой VBист средней руки решает эту задачу не задумываясь.
Насчет фомализации работы дизайнеров, боюсь, что хорошее решение если вообще возможно, то будет настолько сложным, что врубиться в него будет достаточно непросто. Рисовать контролы в режиме What You See Is What You Get намного проще для типичного программиста и дизайнера.
3. Опции программы как раз вещь очень распространенная, есть практически в любой серьезной программе. Достаточно неприятно, когда уже с такой простой вещью возникают проблемы.
1. mapStateF' f st = let st' = f st in (st',[st'])тогда counter n = n+1
"Задуматься и что-то изобретать" мне пришлось из-за явно выраженного недетерминизма в этой задаче. Из-за того, что оба виджета ввода работают параллельно и поставляют данные по отдельности, асинхронно.
Простому программисту это не видно, что ж поделать.
Формализация работы дизайнера необходима для сколько-нибудь большого приложения. Решение это не очень сложное, находится в районе QOCA (hierarchical linear constraint solver). Это чуть-чуть сложнее, чем симплекс.
3. Не возникает с ней проблем. Не возникает.
Все "проблемы с опциями" - это требование, чтобы они лежали в глобальных переменных. Убери его и все станет на свои места.
Мне проще опустить объявление типов и потратить пять-десять минут в день на поиск ошибки, чем всюду их писать и постоянно менять (программа у меня меняется весьма сильно).
1. Ужос какие навороты. Извеняюсь, не до конца их просек, но вообще-то там как минимум еще должно фигуриривать слово Click, так что это еще не окончательная версия. :)
Если бы такая формализация работы дизайнера была бы действительно нужна, и реализации ее имеются, то почему эти реализации еще не захватили рынок? Что-то тут не так.
2. Если говоришь, что решение без глобальных переменных простое, то как насчет его написать в порядке практики работы с виджетами? :) Пусть нам надо реализовать окно с двумя полями, которое редактирует какие-то получаемые извне значения (не важно, какого типа) и по нажатию кнопки "Ok" возвращает то, что было введено, по нажатию кнопки "Cancel" возвращает исходные значения. Как передаются и возвращаются значения - не важно, можешь выбрать удобную для себя форму. Если интересно, со своей стороны могу предоставить для сравнения решение на визуальном средстве (оно совершенно тривиальное, думаю, напишется минуты за три).
counterF = intDispF >==< mapstateF count 0 >==< buttonF "Up" count n Click = (n+1,[n+1])Теперь заменится на -- Где-то в глубине библиотеки. Или нашей обертки над ней: mapStateF' f startSt = mapStateF aux startSt where aux st inp = let r = f st inp in (r,[r])
-- измененный код: counterF = intDispF >==< mapstateF' count 0 >==< buttonF "Up" count n Click = n+1Теперь и Click есть, и все остальное.
На библиотеку Qt смотрел? Там все примерно так и сделано. Но есть и визуальный редактор.
2.Как только замусь GUI, а не моделированием аппаратуры, сразу же. Ты узнаешь об этом одним из первых (если, конечно, будешь читать мой журнал).
Фуджетов я не знаю. Монаду для разборщиков написал с помощью потоковых процессоров, вот и все.
Точнее In 1991, Haavard started writing the classes that eventually became Qt, collaborating with Eirik on the design. The following year, Eirik came up with the idea for "signals and slots", a simple but powerful GUI programming paradigm that has now been embraced by several other toolkits. Haavard took the idea and produced a hand-coded implementation. By 1993, Haavard and Eirik had developed Qt's first graphics kernel and were able to implement their own widgets. At the end of the year, Haavard suggested that they go into business together to build "the world's best C++ GUI framework". On May 20, 1995, Qt 0.90 was uploaded to sunsite.unc.edu. Six days later, the release was announced on comp.os.linux.announce. This was Qt's first public release. Qt could be used for both Windows and Unix development, offering the same API on both platforms.
Delphi 1 писалась в 93-95 годах и релиз был тоже в 1995, а вот Visual Basic 1.0 был выпущен в 1991 и развивался до 1997. Как VB выглядел, никогда не интересовался, а вот Delphi 1 помню хорошо, там уже было всё хорошее, кроме frames (контейнеров, на которые можно лёгким движением руки положить компоненты и другие фреймы, а потом это всё использовать как единое целое).
counterF = intDispF >==< mapstateF count 0 >==< buttonF "Up"
count n Click = (n+1,[n+1])
И это вместо тривиального оператора
control.value = control.value + 1;
Налицо качественное усложнение программы, причем на ровном месте.
Калькулятор там тоже очень сложный для понимания. Откровенно говоря, не думаю, что многие из местных хаскельных программистов смогут такое воспроизвести без заглядывания в тот исходик. Между тем, в визуальных средствах калькулятор делается вообще без какого-либо напряжения сознания.
2. Понятно что отвергаем, ведь в Хаскелле выбора-то нет - там можно писать только функционально, такую императивность он не поддерживает. Между тем, ввели бы там мутабельные переменные как в ML, мощность языка от этого только возросла бы.
3. Вообще-то в императивном подходе сделать редактирование каких-то значений, лежащих в глобальных переменных очень просто - надо всего два оператора на каждое значение - один копирует значение глобальной переменной в контрол при создании формы, второй - копирует назад при закрытии формы. И никаких ненужных наворотов.
Да, и использовать конфиг в императивном подходе тоже проще - глобальные переменные доступны в любом месте программы, а в функциональном варианте надо этот конфиг передавать как параметр во все места, где он может понадобиться (а на практике таких мест может быть очень много). Налицо преимущество и в этом вопросе императивного программирования.
Reply
Поэтому усложнение на ровном месте.
BTW, написание преобразующих состояние функций (i -> st -> (o,st)) проще, чем написание изменения глобального состояния. Это мой личный опыт (моделируя аппаратуру на C++, я пришел к такому же стилю программирования) и опыт товарищей из Эрланга.
Визуальные средства не дают декларативности. Вместо диалога, подходящего под look-n-feel текущей операционки мы полчаем именно кнопочки и именно "вот такую вот иконку."
2.Data.IORef
Им мало, кто пользуется. Только по необходимости.
3.Это хорошо, когда у тебя одна форма. Теперь представь, что одна и та же форма используется в паре-тройке мест, в других разных формах. Уже станет менее удобно.
И там далее сложность все увеличивается.
Протаскивание конфигурации накладно, но полезно. Видно, кто этим пользуется.
Если очень охота - state monad. Функционально и протаскивание скрыто.
Reply
Мне, кстати, не нравиться, что логика там свалена в одну кучу с инициализацией. А если надо что-то в свойствах контрола поменять, фонт, допустим, это тоже пойдет в эту кучу? Это же такое нагромождение получиться. Намного удобнее, когда можно получить доступ ко всем пропертям и обрабатываемым эвентам контрола через специальное окошко, как это сделано в BCB/Дельфи.
Визуальные средства как правило вообще непереносимые (компилируют только под одну платформу). Это, конечно, недостаток. С другой стороны, зато они позволяют (в отличие от самовыравнивающихся контролов) делать всякие дизайнерские изыски и прочие радости ручной настройки. Вот понадобиться, допустим, в калькуляторе выводить надцать знаков числа и вдруг окажется, что имеющегося размера поля для этого не хватает т.е. его надо увеличивать. Как это сделать в самонастраивающейся программе, если при этом заодно требуется для красоты изменить и размеры всех кнопочек, чтобы матрица с ними была такой же ширины?
2. Ага, значит таки есть. Рад за Хаскель. Правда до меня постепенно доходит, что в ленивом языке пользоваться такой штукой можно только поотключав эту ленивость нафиг, иначе могут начаться глюки. Поэтому наверное и мало пользуются.
3. Вообще-то речь изначально была о редактировании опций программы, для этого глобальные переменные отлично подходят. Но в принципе привязать такое окно к редактированию какого-то объекта, заданного ссылкой, не так уж и сложно.
Насчет state monad я не очень понимаю. А разве не надо ее задавать в описании типа функции (для чего тоже надо возиться)? Разве использование монады может быть полностью выведено автоматически?
Кстати, как тебе понравилось мнение того дяди, который сказал, что неописывать типизацию функций в Хаскеле чревато тем, что он начинат выдавать сообщения об ошибках в местах, находящихся весьма далеко от реального места ошибки? Ты с таким сталкиваешься?
Reply
Даже по числу символов меньше. ;)
Дизайнер должен сказать, что "вот здесь вот такие ограничения, а вот в этой форме поддерживать соотношение сторон самой формы и вот этих кнопочек внутри близким к золотому сечению, и чтобы шрифт кнопок масштабировался соответственно, а вот в этой форме все совсем по другому, там надо..." Или даже так: "Все формы и подформы должны иметь соотношение сторон, близкое к золотому сечению, все формы сопровождаются указанием важности элементов, элементы с одинаковой важностью должны располагаться в ряд или столбец."
Дело программиста - запрограммировать все эти ограничения. И, кстати, вытянуть их из дизайнера. ;)
Максимум, что от дизайнера требуется сделать вручную - это примерно показать расположение элементов формы.
2. С ленивыми вычислениями справляется IO. Почему они и называются IORef.
3. Использование монады будет выведено автоматически.
Глобальные переменные "опции программы" - это очень и очень частный случай. Редко встречающийся. Интереснее рассмотреть случай пообщее.
Мнение какого дяди?
Да, кстати, я с этим сегодня столкнулся. Функция в другом, недавно модифицированном, но еще не отлаженном модуле начала принимать списки [a] вместо просто a. Пришлось потратить около десяти минут, чтобы это исправить. Забыл в одном месте concatMap.
Reply
Насчет фомализации работы дизайнеров, боюсь, что хорошее решение если вообще возможно, то будет настолько сложным, что врубиться в него будет достаточно непросто. Рисовать контролы в режиме What You See Is What You Get намного проще для типичного программиста и дизайнера.
3. Опции программы как раз вещь очень распространенная, есть практически в любой серьезной программе. Достаточно неприятно, когда уже с такой простой вещью возникают проблемы.
Дядя - это из моего поста в ru_lambda.
Ты же, как я понял, проблемы из-за отсутствия декларации типов получаешь, но тем не менее продолжаешь эти декларации опускать?
Reply
mapStateF' f st = let st' = f st in (st',[st'])тогда
counter n = n+1
"Задуматься и что-то изобретать" мне пришлось из-за явно выраженного недетерминизма в этой задаче. Из-за того, что оба виджета ввода работают параллельно и поставляют данные по отдельности, асинхронно.
Простому программисту это не видно, что ж поделать.
Формализация работы дизайнера необходима для сколько-нибудь большого приложения. Решение это не очень сложное, находится в районе QOCA (hierarchical linear constraint solver). Это чуть-чуть сложнее, чем симплекс.
3. Не возникает с ней проблем. Не возникает.
Все "проблемы с опциями" - это требование, чтобы они лежали в глобальных переменных. Убери его и все станет на свои места.
Мне проще опустить объявление типов и потратить пять-десять минут в день на поиск ошибки, чем всюду их писать и постоянно менять (программа у меня меняется весьма сильно).
Reply
mapStateF' f st = let f' = let st' = f st in (st',[st']) in mapState f' stТеперь более правильно.
Reply
Если бы такая формализация работы дизайнера была бы действительно нужна, и реализации ее имеются, то почему эти реализации еще не захватили рынок? Что-то тут не так.
2. Если говоришь, что решение без глобальных переменных простое, то как насчет его написать в порядке практики работы с виджетами? :) Пусть нам надо реализовать окно с двумя полями, которое редактирует какие-то получаемые извне значения (не важно, какого типа) и по нажатию кнопки "Ok" возвращает то, что было введено, по нажатию кнопки "Cancel" возвращает исходные значения. Как передаются и возвращаются значения - не важно, можешь выбрать удобную для себя форму. Если интересно, со своей стороны могу предоставить для сравнения решение на визуальном средстве (оно совершенно тривиальное, думаю, напишется минуты за три).
Reply
counterF = intDispF >==< mapstateF count 0 >==< buttonF "Up"
count n Click = (n+1,[n+1])Теперь заменится на
-- Где-то в глубине библиотеки. Или нашей обертки над ней:
mapStateF' f startSt = mapStateF aux startSt
where
aux st inp = let r = f st inp in (r,[r])
-- измененный код:
counterF = intDispF >==< mapstateF' count 0 >==< buttonF "Up"
count n Click = n+1Теперь и Click есть, и все остальное.
На библиотеку Qt смотрел? Там все примерно так и сделано. Но есть и визуальный редактор.
2.Как только замусь GUI, а не моделированием аппаратуры, сразу же. Ты узнаешь об этом одним из первых (если, конечно, будешь читать мой журнал).
Фуджетов я не знаю. Монаду для разборщиков написал с помощью потоковых процессоров, вот и все.
Все собираюсь освоить, но руки не доходят.
Поэтому - засчитывай мне слив.
Reply
Reply
И какой она была?
Reply
In 1991, Haavard started writing the classes that eventually became Qt, collaborating with Eirik on the design. The following year, Eirik came up with the idea for "signals and slots", a simple but powerful GUI programming paradigm that has now been embraced by several other toolkits. Haavard took the idea and produced a hand-coded implementation. By 1993, Haavard and Eirik had developed Qt's first graphics kernel and were able to implement their own widgets. At the end of the year, Haavard suggested that they go into business together to build "the world's best C++ GUI framework".
On May 20, 1995, Qt 0.90 was uploaded to sunsite.unc.edu. Six days later, the release was announced on comp.os.linux.announce. This was Qt's first public release. Qt could be used for both Windows and Unix development, offering the same API on both platforms.
Delphi 1 писалась в 93-95 годах и релиз был тоже в 1995, а вот Visual Basic 1.0 был выпущен в 1991 и развивался до 1997. Как VB выглядел, никогда не интересовался, а вот Delphi 1 помню хорошо, там уже было всё хорошее, кроме frames (контейнеров, на которые можно лёгким движением руки положить компоненты и другие фреймы, а потом это всё использовать как единое целое).
Исходников первой Qt не нашёл, только списки изменений.
Reply
Судя по всему, Fudgets не сильно сложнее в разработке, чем Qt. ;)
Reply
Reply
Ты про сам тулкит или про приложения?
Reply
А почему до Дельфи далеко?
Reply
Leave a comment