граммофон wrote:
> C>Точно так же ведь можно и обычные виртуальные функции заменить switch'ем
> C>(как частный случай pattern-matching'а). Но вот проблема в том, что
> C>виртуальные функции как раз придумали чтобы заменить switch
> А классы придумали, чтобы заменить указатели на функции.
> Хорошая такая замена!
Нет, не указатели на функции, а набор указателей на функции.
Почуствуй разницу.

Заодно над этим набором потом вводят дополнительную функциональность —
наследование, выделение интерфейсов и т.п.

> Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода,
> чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.
Ну-ка, продемонстрируй "в 10 раз меньше" на С.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.

<a href="http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/">Fudgets</a> видел?
Можно создавать виджеты (что значит динамически??), можно менять состояния (если имеется в виду button.setTitle("New")), не всё как в нормальной, разумеется, например, я не знаю как менять look&feel, кроме как через параметры, но функциональный подход демонстрирует.

А вообще есть толпа библиотек http://haskell.org/haskellwiki/Libraries_and_tools/GUI_libraries

Правда, многие — калька с императивных (один из самых популярных, wxhaskell например). Но подход fudgets очень симпатичный — мне нравится больше, чем ООшный.

Здравствуйте, граммофон, Вы писали:

Г>Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.

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

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений.
Для Ерланга есть другая либа gtkNode
---------------------------------------------------------
Yet Another GUI framework for Erlang — gtkNode

DESIGN GOALS

* GUI separated from application by message passing
* distributed (application and GUI can run on different machines)
* centered around a GUI builder
* small volume of (hand-written) code
* pre-documented

ARCHITECTURE

a c-node (a daemon that implements the Erlang distribution protocol)
that instantiates the GUI from a configuration file. the c-node sends
messages to the Erlang node when the user interacts with the GUI; the
Erlang application changes the state of the GUI by sending messages to
widgets in the c-node. the widgets should look like Erlang processes
with registered names. the protocol should look something like this.

CnodePid ! {aWidget,dosomething,Args} % erlang->cNode
ApplicationPid ! {reply, Val} % cNode->Erlang
ApplicationPid ! {signal,aWidget,eventType} % cNode->erlang
-------------------------------------------------------------
использует GTK. можно строить ГУЙ при помощи GLADE.
Но, конечно, все на сообщениях...

LCR>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.
А все это можно — сообщения и процессы "спасут отца русской демократии" ! 8))

Здравствуйте, FDSC, Вы писали:

T>>"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."
T>>Три условия должны выполняться одновременно.
T>>Для ФЯ это никуда не девается, но получить получается легче.

FDS>Личное мнение. Бездоказательное.

??? Сергей же подчеркнул, то что сказали Вы — что чтобы получить так как в ФЯ (устранить оверхед) необходимо чтобы выполнялись три условия (да Вы и сами это написали). В ФЯ же их выполнять не надо в силу природы ФП — у него нет переменных, только values. Что тут доказывать и где тут личное мнение?

Здравствуйте, FR, Вы писали:

L>>Ты можешь что нибудь предложить?

FR>GUI :)

И ты, Брут! :-) См. ответы выше.

Здравствуйте, FR, Вы писали:

Г>>Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.

FR>ОО языки они разные бывают, на динамических почти все паттерны тоже сильно вырождаются и особо не нужны.

Ну не совсем, даже в классической книге GoF'а примеры на Смолтолк.
Хотя во некоторых случаях твоя правда, ага.

Здравствуйте, Cyberax, Вы писали:

C>Ну-ка, продемонстрируй "в 10 раз меньше" на С.

В простейшем случае просто один указатель на функцию заменяется другим. Без оглядки на типы и прочее.
Что в рамках ООП не имеет смысла.
Другое дело, что таких простейших случаев — большинство.

Сидеть же и считать этот синтаксически оверхед от описания классов и интерфейсов лень.
Уж не знаю в 10 раз там разница или в 9,5 — мне хватает.

Здравствуйте, lomeo, Вы писали:

L>Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.

L>Ты можешь что нибудь предложить?

Любые задачи эмуляции чего-то с сотоянием. Особенно если требуется получить быстрое решение с малым расходом памяти.

Здравствуйте, lomeo, Вы писали:

L>Вот ты говоришь — сахар, сахар. ОО — это же тоже сахар, в таком случае. Но одновременно это и способ мышления. Когда я пишу на ОО, я думаю в объектах, когда на ФЯ — в действиях. Поэтому сахар тут не при чём. Дело в том, что (по моему опыту) думать в объектах приходится больше, чем в действиях. И это понятно — Гапертон объяснил почему. А разница в этих двух "думать" и есть оверхед, который создаёт ОО.

Когда я думаю, то оверхэда не бывает. Оверхэд получается когда я пытаюсь выразить свои мысли в виде кода.

Так вот его то сахар и убирает. Во многих ООЯ сахара просто недостаточно. От того и выражение мыслей бывает более длинным и запутанным.

Вот когда я пишу на том же Немерле подоставляющем тот самый сахар не только для функциональной, но и для императивной части, то оверхэда получается не много. Сишные скобки и то больше создают. От того и решения получаются помпактными и понятными.

И вообще, большой вопрос что считать функциональным, а что императивным. Лично я считаю фунциональным стиль программирования в котором программист старается использовть вычисление выражений вместо выполнения инструкций. Гапертон же тут рядом заявил, что если в программе используется модификация переменных, то это уже "императивщина" (таки оскорбление какое-то ).

Так вот можно без проблем писать очень компактный и выразительный код во всю используя модификацию переменных. И программа от этого сложнее не или непонятнее не станет. Так что если определять ФП как это делает Гапертон, то ФП вообще мало чего дает.

Я считаю, что пропагандируемем выразительность ФП в основном основывается на сахаре добавленном в ФЯ. Так я бы выделил:
1. Сопоставление с образцом (сахар для if-ов и switch-ей).
2. Алгеброические типы (сахар для классов).
3. Спец.синтаксис (сахар для работы со списками, строками, и т.п.).
4. Операции над функциями (частичное применение, локальные функции, лямбды).

Вроде ничего не забыл. Вот эти составляющие и опеделяют выразительность. А сказки про то что изменение переменных ужасно усложняет программу, они и есть сказки. Я не испытвал проблем с этим в C# нигогда. Достаточно было выполнять несколько простых правил и проблема исчезала сама собой.

Меж тем модификация переменных иногда может быть очень полезна даже если используется весь перечисленный выше сахар. Ни один из приведенных аспектов не противоречит императивному программированию. Не мудренно что из ФЯ в таких условиях пытаются сделать религию.

Здравствуйте, Cyberax, Вы писали:

C>Для некоторых — да. Но многие паттерны (типа визитора или прокси)

Вот как раз Посетитель то становится довольно бессмысленным при наличии паттерн-матчинага и алгеброических типов. Что-то ни в одном языке с этими фичами Посетителей не видать.

Здравствуйте, Gaperton, Вы писали:

G>Почему нет? Говорить про Эрланг — там с компонентностью все более чем в порядке, и ничего больш не нужно. Благодаря, конечно, процессам — они выполняют роль объектов при крупноблочной декомпозиции системы.

Вывод. Эрланг — это ООП глазами функционального программиста.

Здравствуйте, Кодт, Вы писали:

К>Так ведь и полиморфизм сделать — не есть большая сложность. Тип интерфейса — кортеж сигнатур функций. Реализация — замыкания функций на общую структуру данных.

Вот только это и есть ООП. Так что ООП это другой взгляд на мир. ФП и ООП могут выражаться друг через друга, а стало быть легко могут сосуществовать в рамках одной модели и даже одного языка. Собвстенно сейчас это как раз и делатся. Началось все в ОКамле (видимо) и развивилось в кучу языков. И по-моему это правильно.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Функции Высшего Порядка = HOF = Higher Order Functions

Значит ВВП = Володя Высего Порядка.

Здравствуйте, lomeo, Вы писали:

FR>>ОО языки они разные бывают, на динамических почти все паттерны тоже сильно вырождаются и особо не нужны.

L>Ну не совсем, даже в классической книге GoF'а примеры на Смолтолк.
L>Хотя во некоторых случаях твоя правда, ага.

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

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, FR, Вы писали:

L>>>Ты можешь что нибудь предложить?

FR>>GUI

L>И ты, Брут! См. ответы выше.

Смотрел, правда давно, но помню по сравнению с ОО вариантами (особенно tk и tkinter) не впечатлило.
Вообще конечно интересно бы посмотреть во что выльется на чисто функциональных библиотеках хотя бы простейшее окно с кнопкой при нажатии на которую это окно закрывается, я думаю вряд ли получится проще чем это:

from Tkinter import *

Button(text = "test", command = Tk().quit).pack()
mainloop()

граммофон wrote:
> C>Ну-ка, продемонстрируй "в 10 раз меньше" на С.
> В простейшем случае просто один указатель на функцию заменяется другим.
> Без оглядки на типы и прочее.
То ставится функция другого типа?

void (*ptr)(int p1, p2);

void func1(int p1, int p2)
{
//...
}

double func1(double p1, double p2)

ptr=((void*)(int,int))func1;
ptr(1,2); //Упс.

Так что ли?

> Что в рамках ООП не имеет смысла.
> Другое дело, что таких простейших случаев — большинство.
Нет. Интерфейс из одной функции я вижу ну очень редко — это как раз
редкий частный случай.

> Сидеть же и считать этот синтаксически оверхед от описания классов и
> интерфейсов лень.
> Уж не знаю в 10 раз там разница или в 9,5 — мне хватает.
> прежде чем понять рекурсию, необходимо понять рекурсию.
Покажи пример.

VladD2 wrote:
> C>Для некоторых — да. Но многие паттерны (типа визитора или прокси)
> Вот как раз Посетитель то становится довольно бессмысленным при наличии
> паттерн-матчинага и алгеброических типов. Что-то ни в одном языке с
> этими фичами Посетителей не видать.
Визитор нужен для разделения обхода и обработки. Например, FR приводил
пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный
метод, а так его можно просто разбить на разные классы.

FR>Смотрел, правда давно, но помню по сравнению с ОО вариантами (особенно tk и tkinter) не впечатлило.
FR>Вообще конечно интересно бы посмотреть во что выльется на чисто функциональных библиотеках хотя бы простейшее окно с кнопкой при нажатии на которую это окно закрывается, я думаю вряд ли получится проще чем это:
FR>

FR>from Tkinter import *

FR>Button(text = "test", command = Tk().quit).pack()
FR>mainloop()
FR>

A simple pocket calculator

import Fudgets

main = fudlogue (shellF "Pocket Calculator" calcF)

calcF = intDispF >==< mapstateF calc [0] >==< buttonsF

data Buttons = Plus | Minus | Times | Div | Enter | Digit Int   deriving (Eq)

buttonsF = placerF (matrixP 4) (
              listF [d 7, d 8, d 9,op Div,
                     d 4, d 5, d 6,op Times,
                     d 1, d 2, d 3,op Minus,
                     hole,d 0,ent, op Plus])
  where
    d n = (Digit n,buttonF (show n))
    ent = op Enter
    hole = (Enter,holeF)
    op o = (o,buttonF (opLabel o))
      where opLabel Plus = "+"
            opLabel Minus = "-"
            opLabel Times  = "*"
            opLabel Div = "/"
            opLabel Enter = "Ent"

calc (n:s)   (Digit d,_) = new (n*10+d) s
calc s       (Enter,_)   = (0:s,[])
calc (y:x:s) (Plus,_)    = new (x+y) s
calc (y:x:s) (Minus,_)   = new (x-y) s
calc (y:x:s) (Times,_)   = new (x*y) s
calc (y:x:s) (Div,_)     = new (x `div` y) s
calc s       _           = (s,[])

new n s = (n:s,[n])

Неподалеку от него есть и Helloworlds!, и с кнопками тоже.

Здравствуйте, FDSC, Вы писали:

FDS>Личное мнение. Бездоказательное.