Курилка wrote: > C>Не знаю как проще объяснить — вероятно придется писать статью > Было бы интересно почитать
Я уже должен одну статью в форум про Java написать Так что буду
заниматься во время отпуска.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Статью пока не читал, но с твоих слов выглядит что статья очередной бред.
L>Пастернака не читал, но осуждаю
Сочувствую тебе, но Пастернак тут не причем. Изложенное Курилкой вообще характерно для пиара ФЯ. И читал я подобные вещи много раз.
"Пастернака" тоже прочу, но позже. Вот только вышел на работу после отпуска. Надо дела разгребать.
L>
L>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией
Мне эти слова кажутся спорными.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Ты программируешь основываясь на ощущениях?
Сложный вопрос. Точно могу сказать, что по крайней мере масса предпочтений делается на ощущениях. Тот же стиль кодирования, например, чистой воды предпочтение на ощущениях и привычках.
К>ФП и ООП не противопоставляются и могут существовать, есть же и окамл и клос в лиспе и ещё много чего.
С этой мыслью полностью согласен.
К>Только вот объекты в данном случае получаются зачастую излишни и задача декомпозируется без них.
А с этой не совсем. И вообще, что за зверь "объекты"? Какой-то расплывчатый термин. Например, фраза "first class object" о них говорит?
Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена? Мне кажется, что для некоторых задачь классы отличный выбор. Хотя для других может быть и не лучший. В общем, это зависит от задачи и от требований. Не вижу смысла вообще противопоставлять ООП и ФС.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Влад уже привел пример когда у объекта нет изменяемого состояния.
G>>Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.
G>>Господи, объясните ему кто-нибудь.
FR>Лучше дай правильное по твоему определение объекта.
С этого стоило начать. Есть классическое определение объекта от Кея, которое неоднократно приводилось в философии.
Сводится в результате оно к следующему.
1) Объект имеет состояние. При этом неявно подразумевается, что оно вообще говоря mutable, т.е. изменяемое.
2) Объект имеет identity — если identity совпадает, то это один и тот же объект. Объекты с разным identity могут быть одинаковы, это делу не мешает. == у объекта возможны модифицирующие операции, наличие identity с этим тесно связанно, как и с предыдущим пунктом.
3) Объект сам решает, как обработать "сообщение" == к состоянию объекта нет прямого доступа, оно спрятано == класс объектов определяется не структурой состояния, а набором операций над ним == Abstract Data Type. Смоллтокер тут придерется насчет знаков равенства, по понятной причине но в нашем случае не так принципиально.
Пункт 3 — ADT (Абстрактный Тип Данных, определяющийся набором операций), вообще говоря не подразумевает соблюдения пунктов 1 и 2, и встречается поодиночке. Например, в Хаскеле. Или в Эрланге — т.н. "абстрактный модуль."
То, что вы приводите в качестве объекта, безусловно является ADT, но лишен (изменяемого) состояния. Т.е. вместо изменения вы должны возвращять его измененную копию, таким образом, все его определение состоит из чистых функций. Фундаментальное отличие экземпляра ADT от объекта состоит в отсутствии identity и инкапсулированного состояния. ADT без состояний невозможно использовать для декомпозиции и моделирования сложной системы, так, как это принято в ООП. ADT не "моделирует реальный мир", как это делают объекты (каждый прячет в себе часть состояния, которое меняется во времени). Для декомпозиции аналогичной объектной в случае применений чистых функций придется использовать технику потоков. Это все достаточно подробно описано в SICP, кстати, который вы мне цитируете.
Когда вы рассматриваете один класс, казалось бы все нормально — делаем методы конст, и все. Проблему вы увидите, когда попробуете в реальном дизайне средней сложности (где обязательно присутствуют кольцевые ссылки) сделать все методы константными. Она будет состоять в том, что вы при таком подходе не сможете скоординированно поменять состояние системы — она расползется на копии. При этом, никто не мешает вам часть системы выполнить в этом принципе — это часто бывает полезно.
G>>>>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изобразишь никогда.
FR>>>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код: G>>ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.
FR>Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"
Стоп. Во-первых, в статье автор ничего кроме Эрланга из ФП не пробовал, так что его "ФП" надо сузить до возможностей Эрланга. В котором, по ходу дела, объекты в смоллтоковском стиле есть — они там правда большие и незаметные , процессами моделируются. А вот изменять значения замкнутых переменных там как раз низзя.
Во-вторых, "грязный ФП" это чистый ФП + императивщина. Смесь это. Нет такого отдельного понятия. Когда вы ищете преимуществ ФП перед ООП (подразумевающим работу с изменяемым состоянием, иначе никакой это не ООП), то глупо принимать во внимание императивную составляющую грязного ФП, никакого преимущества перед ООП она дать не может в принципе.
Тем более, что автор статьи, упоминая фичи ФП, всегда аппелирует к чистоте. А вы тут "грязные" замыкания из грязных лиспов со схемами мне в качестве плюса ФЯ приводите, которых автор статьи, кстати, в глаза не видел. С тем же успехом можно насквозь императивный Алгол-68 за ФЯ посчитать — там тоже замыкания есть.
Здравствуйте, VladD2, Вы писали:
VD>А с этой не совсем. И вообще, что за зверь "объекты"? Какой-то расплывчатый термин. Например, фраза "first class object" о них говорит?
[flame]
О! Кстати! Почему об этом ещё молчат?
Язык может считаться полноценным ОО в том случае, если класс в нём является first class object. Вот, например, Python или JavaScript.
А то, понимаешь, в ФЯ можно писать функции высшего порядка, а в С++ метаклассы только с помощью велосипедов с квадратными колёсами делаются.
[/flame]
Здравствуйте, Cyberax, Вы писали:
C>Громоздко, но возможно.
Ай-ай-ай.
1) А чего это ты к приватному состоянию B из класса A лезешь? Инкапсуляцию нарушаем? Нехорошо!
2) Ты забыл из нутра метода mutate_something вызвать подобный метод класса В. Вот тут самое интересное начнется, а ты это заинтересованной общественности не показал.
Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и все они друг друга по ассоциациям дергать начнут за методы mutate some shit. Повеселимся?
Gaperton wrote: > C>Громоздко, но возможно. > Ай-ай-ай. > 1) А чего это ты к приватному состоянию B из класса A лезешь? > Инкапсуляцию нарушаем? Нехорошо!
Детали, считай это просто частью конструирования объекта.
> 2) Ты забыл из нутра метода mutate_something вызвать подобный метод > класса В. Вот тут самое интересное начнется, а ты это заинтересованной > общественности не показал.
Да без проблем — сначала получаем измененный объект A в связке с B.
Дергаем метод у B и получаем еще одну новую связку A-B и возвращаем из
нее объект A в качестве результата.
> Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и > все они друг друга по ассоциациям дергать начнут за методы mutate some > shit. Повеселимся?
Для большей сложности, естественно, нужен общий механизм (чтобы все это
не писать каждый раз).
Здравствуйте, Кодт, Вы писали:
К>[flame] К>О! Кстати! Почему об этом ещё молчат? К>Язык может считаться полноценным ОО в том случае, если класс в нём является first class object. Вот, например, Python или JavaScript. К>А то, понимаешь, в ФЯ можно писать функции высшего порядка, а в С++ метаклассы только с помощью велосипедов с квадратными колёсами делаются. К> К>[/flame] К>
Ради справедливости... В Яве классы first class object их можно создавать где угодно, без имен, с замыканиями и даже передовать другому коду по ссылке, да и вообще посылать куда по дальше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>В Эрланге, о котором и говорил автор статьи, такой возможности нет. Эта возможность — императивна, это не ФП, глупо ее противопоставлять ОО, и не важно, присутствует она в языках или нет. Что вы мне все тут доказать хотите?
Вывод. ФП + ИП == ООП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Пастернака не читал, но осуждаю :-)
VD>Сочувствую тебе, но Пастернак тут не причем. Изложенное Курилкой вообще характерно для пиара ФЯ. И читал я подобные вещи много раз.
Что плохого в пиаре ФЯ? То, что ты подобное читал много раз?
VD>"Пастернака" тоже прочу, но позже. Вот только вышел на работу после отпуска. Надо дела разгребать.
Аналогично :-(
L>>
L>>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией
Здравствуйте, Cyberax, Вы писали:
>> 1) А чего это ты к приватному состоянию B из класса A лезешь? >> Инкапсуляцию нарушаем? Нехорошо! C>Детали, считай это просто частью конструирования объекта.
Ок, это придирки, согласен.
>> 2) Ты забыл из нутра метода mutate_something вызвать подобный метод >> класса В. Вот тут самое интересное начнется, а ты это заинтересованной >> общественности не показал. C>Да без проблем — сначала получаем измененный объект A в связке с B. C>Дергаем метод у B и получаем еще одну новую связку A-B и возвращаем из C>нее объект A в качестве результата.
А что произойдет с указателем на объект B из объекта С? И с указателем на объект А из объекта D? Они будут указывать на старый объект, не измененный — не так ли?
>> Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и >> все они друг друга по ассоциациям дергать начнут за методы mutate some >> shit. Повеселимся? C>Для большей сложности, естественно, нужен общий механизм (чтобы все это C>не писать каждый раз).
Да не сделаешь ты такой механизм. Нельзя его сделать в общем случае.
lomeo,
VD>>Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена?
L>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.
Классная идея.
Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).
Ссылки у меня к сож. нет, осталась распечатка только.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).
Мне более интересно не как создать клон (это то просто), а как решать задачи, которые решает паттерн, но используя функциональный подход.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).
L>Мне более интересно не как создать клон (это то просто), а как решать задачи, которые решает паттерн, но используя функциональный подход.
Вот это смотрел? Здесь, насколько я помню, о том, что в языках Lisp и Dylan большинство паттернов GoF невидимо или тривиально. http://www.norvig.com/design-patterns/
Однако, там упор на динамические свойства языков. В функциональных языках будет примерно то же самое, даже в строготипизированных, благодаря pattern-matching. Основная причина появления "паттернов" в ООП состоит в ограниченности динамического полиморфизма в модели ОО — вызов диспетчеризуется только по одному аргументу (this). Это заставляет в мало-мальски сложном случае городить лес из классов, размазывая по ним функционал. ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
Gaperton wrote: > ФЯ с паттерн-матчингом позволяет выполнять другую > группировку функционала, снимая ограничения на полиморфизм. Вот в все. В > ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
Однако, иногда полиморфизм используется именно для того, чтобы как раз
убрать эту группировку. Классический пример — приложение и плугины,
взаимодействие с плугинами идет через интерфейсы/абстрактные классы.
Вероятно поэтому функциональщики предпочитают использовать
message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
заменой.
Здравствуйте, Cyberax, Вы писали:
C>Однако, иногда полиморфизм используется именно для того, чтобы как раз C>убрать эту группировку. Классический пример — приложение и плугины, C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы.
C>Вероятно поэтому функциональщики предпочитают использовать C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной C>заменой.
В Haskell есть классы типов, в ML — функторы.
прежде чем понять рекурсию, необходимо понять рекурсию.
, процессами моделируются. А вот изменять значения замкнутых переменных там как раз низзя.
Вот, например, Python или JavaScript.
Перекуём баги на фичи!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
