Здравствуйте, VladD2, Вы писали:
VD>ФП и ООП могут выражаться друг через друга
Нет.
VD>а стало быть легко могут сосуществовать в рамках одной модели и даже одного языка.
Да.
gandalfgrey,
LCR>>Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений. G>Для Ерланга есть другая либа gtkNode
... G>Но, конечно, все на сообщениях...
Принципиальной разницы между gs и gtkNode нет. Поэтому отметаем.
LCR>>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc. G>А все это можно — сообщения и процессы "спасут отца русской демократии" ! 8))
Да, асинхронный обмен рулит и т.д. и т.п., но где здесь ФП? Напомню, спор вызвал тезис lomeo:
L>Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.
Здравствуйте, Cyberax, Вы писали:
C>Визитор нужен для разделения обхода и обработки. Например, FR приводил C>пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный C>метод, а так его можно просто разбить на разные классы.
Это не совсем точно. Визитор использует разделение обхода и обработки. Но нужен он не для этого.
Описывает операцию, выполняемую с каждым объектом из некоторой структуры. Паттерн посетитель позволяет определить новую операцию, не изменяя классы этих объектов.
Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, VladD2, Вы писали:
VD>>1. Сопоставление с образцом (сахар для if-ов и switch-ей).
ANS>Это ниразу не сахар для if-ов и switch-ей
VD>>2. Алгеброические типы (сахар для классов).
ANS>Ни разу не сахар для классов.
Да лана тебе. Все равно Ифы и Свитчи — сахар для команд JNZ и JZ, а функции — сахар для инструкций CALL и RET.
Здравствуйте, VladD2, Вы писали:
L>>Ты можешь что нибудь предложить?
VD>Любые задачи эмуляции чего-то с сотоянием. Особенно если требуется получить быстрое решение с малым расходом памяти.
Согласен у состояний на ФП много недостатков. Самый неприятный для меня — это добавление в состояние ещё одной переменной. Но ты говоришь о сайд-эффекте, а я об ООП. В данном случае наличие или отсутствие классов не играет роли.
Здравствуйте, lomeo, Вы писали:
C>>Визитор нужен для разделения обхода и обработки. Например, FR приводил C>>пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный C>>метод, а так его можно просто разбить на разные классы.
L>Это не совсем точно. Визитор использует разделение обхода и обработки. Но нужен он не для этого.
L>
Описывает операцию, выполняемую с каждым объектом из некоторой структуры. Паттерн посетитель позволяет определить новую операцию, не изменяя классы этих объектов.
L>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.
Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, lomeo, Вы писали:
L>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.
FR>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.
Кто сказал что внутри одной функции? Мультиметоды на то и мульти- Много их — столько сколько захочешь
Здравствуйте, VladD2, Вы писали:
VD>Когда я думаю, то оверхэда не бывает. Оверхэд получается когда я пытаюсь выразить свои мысли в виде кода.
Оверхед получается из-за того, что о действиях думают как об объектах. Отсюда все эти генераторы, треды, различные менеджеры чего-то там.
VD>Так вот его то сахар и убирает. Во многих ООЯ сахара просто недостаточно. От того и выражение мыслей бывает более длинным и запутанным.
Не согласен. Паттерн матчинг и АТД — не сахар — это подход, другой способ взглянуть на вещи. А уж ФВП сахаром назвать язык не повернётся. А ведь они, может быть, самая важная вещь для обсуждаемого вопроса.
VD>Вот когда я пишу на том же Немерле подоставляющем тот самый сахар не только для функциональной, но и для императивной части, то оверхэда получается не много. Сишные скобки и то больше создают. От того и решения получаются помпактными и понятными.
Воспрос не о императивный vs функциональный, а об объектно-ориентированный vs функциональный и о том, насколько больше приходится держать в голове в случае ОО.
VD>И вообще, большой вопрос что считать функциональным, а что императивным. Лично я считаю фунциональным стиль программирования в котором программист старается использовть вычисление выражений вместо выполнения инструкций. Гапертон же тут рядом заявил, что если в программе используется модификация переменных, то это уже "императивщина" (таки оскорбление какое-то :) ).
Я с ним согласен. Отсутствие сайд-эффекта — одна из очень важных черт ФП, которая даёт ему большие преимущества, их уже не раз перечисляли.
VD>Так вот можно без проблем писать очень компактный и выразительный код во всю используя модификацию переменных. И программа от этого сложнее не или непонятнее не станет. Так что если определять ФП как это делает Гапертон, то ФП вообще мало чего дает.
Не понял, почему?
VD>Я считаю, что пропагандируемем выразительность ФП в основном основывается на сахаре добавленном в ФЯ. Так я бы выделил: VD>1. Сопоставление с образцом (сахар для if-ов и switch-ей). VD>2. Алгеброические типы (сахар для классов). VD>3. Спец.синтаксис (сахар для работы со списками, строками, и т.п.). VD>4. Операции над функциями (частичное применение, локальные функции, лямбды).
Отсутствие сайд-эффекта + функции высшего порядка, по моему, гораздо важнее. Без них код на ФЯ не будет таким выразительным и лаконичным.
VD>А сказки про то что изменение переменных ужасно усложняет программу, они и есть сказки. Я не испытвал проблем с этим в C# нигогда. Достаточно было выполнять несколько простых правил и проблема исчезала сама собой.
Ну так, а в ФП для этого даже не надо выполнять эти правила! Из-за этих правил опять таки в мыслях оверхед.
VD>Меж тем модификация переменных иногда может быть очень полезна даже если используется весь перечисленный выше сахар. Ни один из приведенных аспектов не противоречит императивному программированию. Не мудренно что из ФЯ в таких условиях пытаются сделать религию.
Я сейчас не об императивном говорил, а об объектно-ориентированном. А так — да, понятно, что все эти подходы могут существовать вместе. Важно выделить преимущества и недостатки их друг перед другом. Например, при использовании ОО получается больший оверхед, чем при использовании функциональщины ;-)
Здравствуйте, FR, Вы писали:
L>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.
FR>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.
А?!
data Tree a = Node a | Branch (Tree a) (Tree a)
visit n@(Node _) f = f n
visit t@(Tree l r) f = do
f t
f l
f r
-- один визитор
treeLength _ = update (+1)
-- второй визитор
treeSum (Node a) = update (+a)
treeSum _ = get
Тут проблема точно такая же как в паттерне Visitor — при расширении типа данных приходится проходить по всем посетителям.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Принципиальной разницы между gs и gtkNode нет. Поэтому отметаем.
Разница единственно в том, что в одном случа используется TK, а в другом GTK. В обоих случаях ГУЙ может находиться на другой машине.
LCR>Да, асинхронный обмен рулит и т.д. и т.п., но где здесь ФП? Напомню, спор вызвал тезис lomeo: LCR>[q]
Тут я затрудняюсь привести какой-то особый пример для ГУЯ. Сообщения — они как-то от языка не зависят. Для их обработки весьма хорош и приятен паттерн-матчинг, но это не особенность ФЯ
Вот разве что в Clean был весьма специфичный ГУЙ, прямо заточенный под язык...
L>>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.
FR>>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.
К>Кто сказал что внутри одной функции? Мультиметоды на то и мульти- Много их — столько сколько захочешь
Мы вроде про паттерн матчинг а не мультиметоды, хотя и с их помощью можно решить то что делается визитером.
Здравствуйте, lomeo, Вы писали:
L>Тут проблема точно такая же как в паттерне Visitor — при расширении типа данных приходится проходить по всем посетителям.
Угу про это и речь.
Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций
Здравствуйте, FR, Вы писали:
FR>Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций :)
Это общая проблема switch'ей — они имеет тенденцию распухать.
Здравствуйте, Cyberax, Вы писали:
>> C>Вероятно поэтому функциональщики предпочитают использовать >> C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной >> C>заменой. >> Почему нет? Говорить про Эрланг — там с компонентностью все более чем в >> порядке, и ничего больш не нужно. Благодаря, конечно, процессам — они >> выполняют роль объектов при крупноблочной декомпозиции системы. C>Я тебе приводил мой пример — сейчас я его переписываю в более C>функциональном стиле, но все же полностью не получится. Да и, как бы его C>не ругали, RPC — это удобная вещь.
Дык, объекты, на самом-то деле, рулят . На крупном уровне, для декомпозиции системы. А на мелком, когда через них пытаются полиморфизм выразить на каждый писк — они нифига не рулят, там рулит ФП. И RPC штука хорошая. Просто каждая штука хороша на своем месте.
Мне представляется весьма удобным подход, когда грубая декомпозиция систеы выполнена в больших классах, по ОО-шному, в которые завернуто состояние, и которые внутри описываются по возможности чисто функционально. Причем, вся "грязь" с побочными эффектами вынесена в базовые классы, которые проектируются как часть фреймворка.
Вот так — все на своем месте. Именно так спроектирован пресловутый мегасвитч AXD301. И так принято писать на Эрланге — уже сложившаяся практика, доказавшая свою эффективность и удобство в больших проектах. И, главное — так вполне можно, без проблем, писать на OCaml и Nemerle.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>1. Сопоставление с образцом (сахар для if-ов и switch-ей).
ANS>Это ниразу не сахар для if-ов и switch-ей
Твои знания потрясают.
VD>>2. Алгеброические типы (сахар для классов).
ANS>Ни разу не сахар для классов.
Опять же.
ЗЫ
Целяйся сильнее за свой Смолток. Это то что нужно для того чтобы отстать на век.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
; Purely-functional Object-Oriented System in Scheme
;
; The present code implements a classless, delegation-based OO system, similar
; to those of Self or Javascript. This is a full-fledged OO system with
; encapsulation, object identity, inheritance and polymorphism. It is also
; a purely functional system: there is not a single assignment or
; other mutation in the code below.
;
; A closure (encapsulating a message map, and private parameters if any)
; is the object in this system. Sending a message to an object -- i.e.,
; applying the object to a message selector and arguments, -- results
; in a list. Its head is the object in a new state, having processed the
; message; the rest of the list are the results of the message if any.
; Objects' identity is decided by an eq? predicate applied to the result of
; an 'identity' message. A "set-x" method returns an object with a new state,
; but with the same identity as the source object. An object in a changed
; state is in a sense a "child" of the original object. No wonder
; implementations of "mutation" and inheritance are so similar in this
; OO system.
;
; This code was meant to be "light"; therefore it deliberately uses only the
; most basic Scheme constructions. No macros/syntactic closures are employed
; (although they are certainly possible and appropriate).
;
; This code has been discussed in an article "Re: FP, OO and relations. Does
; anyone trump the others?"
; posted on comp.lang.smalltalk, comp.lang.functional, and comp.lang.scheme
; on Wed Dec 29 05:13:58 1999 GMT, Message-ID: <84c4qe$48j$1@nnrp1.deja.com>
; See also http://pobox.com/~oleg/ftp/Scheme/oop-in-fp.txt
; The article presents a more familiar OO system with mutations, and contrasts
; it with a purely-functional OO system, which is implemented in this present
; file.
...
...
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Много их — столько сколько захочешь
