Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена?
L>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.
Слушай, думал-думал, но так и не понял, что за ФВП? Функциональное что?
граммофон wrote: > C>Вероятно поэтому функциональщики предпочитают использовать > C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной > C>заменой. > В Haskell есть классы типов, в ML — функторы.
Вот если ты на них будешь пытаться сделать то, что описывается в GoF —
то получишь примерно такое же, что и в GoF (за некоторыми исключениями).
Потому как паттерны в GoF — это скорее руководство по тому как
использовать полиморфизм.
Здравствуйте, lomeo, Вы писали:
L>Что плохого в пиаре ФЯ?
Его качество. Он похож на внушение, постоянно скатывается на демагогию и зачастую говорит не всю правду.
Мне кажется, что это путь собрать вокруг ФП маргиналов и демагогов.
L> То, что ты подобное читал много раз?
Что?
L>>>
L>>>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией
VD>>Мне эти слова кажутся спорными.
L>Что именно?
Выделно жирным. ООП конечно же никакого оверхэда не создает. А то что кто-то сравнивает сахар одного языка с прямолинейностью другого — это не недостатки ООП, а недостатки того кто производит сравнения. Выражаясь прямо — очередная лож.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>граммофон wrote: >> C>Вероятно поэтому функциональщики предпочитают использовать >> C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной >> C>заменой. >> В Haskell есть классы типов, в ML — функторы. C>Вот если ты на них будешь пытаться сделать то, что описывается в GoF — C>то получишь примерно такое же, что и в GoF (за некоторыми исключениями). C>Потому как паттерны в GoF — это скорее руководство по тому как C>использовать полиморфизм.
Изначально речь шла о том, что для большинства GoF-паттернов не нужны ни классы, ни перегрузки, ни функторов. Достаточно алгебраических типов и паттерн-матчинга.
И вырождаются они в нечто по 2-3 строчки.
То етсь теряют свой смысл как некий прием.
прежде чем понять рекурсию, необходимо понять рекурсию.
Здравствуйте, Gaperton, Вы писали:
G>Вот это смотрел? Здесь, насколько я помню, о том, что в языках Lisp и Dylan большинство паттернов GoF невидимо или тривиально. G>http://www.norvig.com/design-patterns/
Спасибо! Супер...
G>Однако, там упор на динамические свойства языков. В функциональных языках будет примерно то же самое, даже в строготипизированных, благодаря pattern-matching. Основная причина появления "паттернов" в ООП состоит в ограниченности динамического полиморфизма в модели ОО — вызов диспетчеризуется только по одному аргументу (this). Это заставляет в мало-мальски сложном случае городить лес из классов, размазывая по ним функционал. ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
Хотел собрать всё это в одном месте, для демонстрации (пиара ФП по VladD2)
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> ФЯ с паттерн-матчингом позволяет выполнять другую >> группировку функционала, снимая ограничения на полиморфизм. Вот в все. В >> ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно. C>Однако, иногда полиморфизм используется именно для того, чтобы как раз C>убрать эту группировку. Классический пример — приложение и плугины, C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы.
Ну, это не фокус, прямо скажем. В эрланге, например, есть два ортогональных способа это обеспечить.
1) Модули. На базе них "плагин" делается на раз-два. Просто программа предполагает, что в некотором (заранее неизвестном) модуле объявлены некоторые (заранее известные) функции. Пример — OTP behaviours. Никто не мешает делать так в любом языке. В SML вот, я слышал, имеется какое-то "исчисление модулей", наверняка как раз об этом.
2) Процессы. С ними взаимодействие идет через message-passing, что в случае Эрланга так же естественно, как дышать. Но это по сути своей объекты.
C>Вероятно поэтому функциональщики предпочитают использовать C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной C>заменой.
Почему нет? Говорить про Эрланг — там с компонентностью все более чем в порядке, и ничего больш не нужно. Благодаря, конечно, процессам — они выполняют роль объектов при крупноблочной декомпозиции системы.
Здравствуйте, Cyberax, Вы писали:
G>> ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
C>Однако, иногда полиморфизм используется именно для того, чтобы как раз убрать эту группировку. Классический пример — приложение и плугины, взаимодействие с плугинами идет через интерфейсы/абстрактные классы.
C>Вероятно поэтому функциональщики предпочитают использовать message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной заменой.
Так ведь и полиморфизм сделать — не есть большая сложность. Тип интерфейса — кортеж сигнатур функций. Реализация — замыкания функций на общую структуру данных.
type 'a MatStat = { median: () -> 'a; dispersion: () -> 'a; }
val matstatList : 'a list -> 'a MatStat
def matstatList xs =
let m () = ..... (* считаем сумму, делим на длину, ну и т.д. *)and d () = .....
in { median = m; dispersion = d; }
end
val matstatContinuous : (float -> 'a) -> (float Option, float Option) -> 'a MatStat
def matstatContinuous f (x0,x1) =
let m () = ..... (* численно находим интеграл... *)and d () = .....
in { median = m; dispersion = d; }
end
Здравствуйте, VladD2, Вы писали:
L>>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.
VD>Это было бы очень интересно и полезно. Но не вижу причин противопоставлять одно другому. Есть не мало задачь отлично решаемых с помощью классов.
Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять :-(
Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.
граммофон wrote: > C>Вот если ты на них будешь пытаться сделать то, что описывается в GoF — > C>то получишь примерно такое же, что и в GoF (за некоторыми исключениями). > C>Потому как паттерны в GoF — это скорее руководство по тому как > C>использовать полиморфизм. > Изначально речь шла о том, что для большинства GoF-паттернов не нужны ни > классы, ни перегрузки, ни функторов. Достаточно алгебраических типов и > паттерн-матчинга.
Для некоторых — да. Но многие паттерны (типа визитора или прокси) специально задумывались, чтобы можно было распределять код.
Точно так же ведь можно и обычные виртуальные функции заменить switch'ем
(как частный случай pattern-matching'а). Но вот проблема в том, что
виртуальные функции как раз придумали чтобы заменить switch
Кодт wrote: > C>Вероятно поэтому функциональщики предпочитают использовать > message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной > заменой. > Так ведь и полиморфизм сделать — не есть большая сложность. Тип > интерфейса — кортеж сигнатур функций. Реализация — замыкания функций на > общую структуру данных.
Просто при использовании такого полиморфизма получим тот же GoF.
Собственно, именно это я и пытаюсь сказать.
Здравствуйте, VladD2, Вы писали:
L>>Что плохого в пиаре ФЯ?
VD>Его качество. Он похож на внушение, постоянно скатывается на демагогию и зачастую говорит не всю правду. VD>Мне кажется, что это путь собрать вокруг ФП маргиналов и демагогов.
Мне так не показалось. Но я понял, это ИМХО, так что не буду спорить.
VD>Выделно жирным. ООП конечно же никакого оверхэда не создает. А то что кто-то сравнивает сахар одного языка с прямолинейностью другого — это не недостатки ООП, а недостатки того кто производит сравнения. Выражаясь прямо — очередная лож.
Вот ты говоришь — сахар, сахар. ОО — это же тоже сахар, в таком случае. Но одновременно это и способ мышления. Когда я пишу на ОО, я думаю в объектах, когда на ФЯ — в действиях. Поэтому сахар тут не при чём. Дело в том, что (по моему опыту) думать в объектах приходится больше, чем в действиях. И это понятно — Гапертон объяснил почему. А разница в этих двух "думать" и есть оверхед, который создаёт ОО.
Gaperton wrote: > C>Однако, иногда полиморфизм используется именно для того, чтобы как раз > C>убрать эту группировку. Классический пример — приложение и плугины, > C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы. > Ну, это не фокус, прямо скажем. В эрланге, например, есть два > ортогональных способа это обеспечить. > 1) Модули. На базе них "плагин" делается на раз-два. Просто программа > предполагает, что в некотором (заранее неизвестном) модуле объявлены > некоторые (заранее известные) функции.
Это как раз пример name-based полиморфизма. Просто Erlang — динамический
язык и ему не надо явно выделять наборы сигнатур функций. А если их явно
выделить — получатся старые добрые интерфейсы
> Пример — OTP behaviours. Никто не мешает делать так в любом языке. > В SML вот, я слышал, имеется какое-то "исчисление модулей", наверняка > как раз об этом.
Посмотрю.
> C>Вероятно поэтому функциональщики предпочитают использовать > C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной > C>заменой. > Почему нет? Говорить про Эрланг — там с компонентностью все более чем в > порядке, и ничего больш не нужно. Благодаря, конечно, процессам — они > выполняют роль объектов при крупноблочной декомпозиции системы.
Я тебе приводил мой пример — сейчас я его переписываю в более
функциональном стиле, но все же полностью не получится. Да и, как бы его
не ругали, RPC — это удобная вещь.
lomeo,
L>Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять L>Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.
L>Ты можешь что нибудь предложить?
Хм. Вроде бы у меня есть кандидат — GUI. Батоны, окна, батнклики и проч...
Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений.
Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.
Здравствуйте, thesz, Вы писали:
FDS>> Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП .
T>"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."
T>Три условия должны выполняться одновременно.
T>Для ФЯ это никуда не девается, но получить получается легче.
L>Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять L>Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.
L>Ты можешь что нибудь предложить?
Здравствуйте, Cyberax, Вы писали:
C>Точно так же ведь можно и обычные виртуальные функции заменить switch'ем C>(как частный случай pattern-matching'а). Но вот проблема в том, что C>виртуальные функции как раз придумали чтобы заменить switch
А классы придумали, чтобы заменить указатели на функции.
Хорошая такая замена!
Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.
прежде чем понять рекурсию, необходимо понять рекурсию.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.
Говорить про Эрланг — там с компонентностью все более чем в порядке, и ничего больш не нужно. Благодаря, конечно, процессам 
Перекуём баги на фичи!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( 
не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП 
.
