Здравствуйте, Воронков Василий, Вы писали: ВВ>ООП все-таки предполагает инкапсуляцию состояния.
А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
Здравствуйте, k.o., Вы писали: KO>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно.
Вообще, системы с объектоподобными агентами тот же Танненбаум отделял от ООП в отдельную категорию (у него "object-based" vs. "object-oriented"). Но если уж проводить параллели эрланга с ООП — надо обязательно вспомнить о его параметризованных модулях.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали: ВВ>>ООП все-таки предполагает инкапсуляцию состояния. MC>А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах.
По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Mr.Cat, Вы писали:
MC>>Здравствуйте, Воронков Василий, Вы писали: ВВ>>>ООП все-таки предполагает инкапсуляцию состояния. MC>>А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах. ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Можно, поинтересоваться, реально ли у Вас практически встречаются побочные эффекты из-за состояний ?
Сколько программирую, внутренние состояния приносят только пользу .
Здравствуйте, tripol, Вы писали:
T>Можно, поинтересоваться, реально ли у Вас практически встречаются побочные эффекты из-за состояний ? T>Сколько программирую, внутренние состояния приносят только пользу .
Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Здравствуйте, Воронков Василий, Вы писали: ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Ну не такое уж оно и открытое получается. Вон, в xmonad — монада X по сути определяет набор аксессоров к состоянию x-сервера: http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#t%3AX.
Или в эрланге: у каждого процесса (или актера, если хочешь) свое внутреннее состояние, от других скрытое, которое изменяется само по себе или в ответ на сообщения.
Здравствуйте, Mr.Cat, Вы писали:
MC>Или в эрланге: у каждого процесса (или актера, если хочешь) свое внутреннее состояние, от других скрытое, которое изменяется само по себе или в ответ на сообщения.
Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Я вообще не понимаю, саму суть такой идеологии. Возьмем объекты окружающего мира: человек, компьютер, машина, животное.
Все они имеют внутренние состояния и память и в этом их преимущество. "выворачивать наизнанку" что бы видеть внутреннее
состояние объекта это нормально? да и зачем?
Во-первых, не только инкапсуляцию состояния, но и инкапсуляцию поведения. Ни то, ни другое не противоречит ФП. Проблемы будут только с изменением состояния. При этом ООП не заставляет тебя использование изменяемого состояния. Рассмотрим, например каталог ООП паттернов ГОФ:
Abstract Factory
1) Builder
2) Factory Method
3) Prototype
4) Singleton
5) Adapter
6) Bridge
7) Composite
8) Decorator
9) Facade
10) Flyweight
11) Proxy
12) Chain of responsibility
13) Command
14) Interpreter
15) Iterator
16) Mediator
17) Memento
18) Observer
19) State
20) Strategy
21) Template method
22) Visitor
Из всех этих паттернов только Builder, Iterator и State в классической реализации предполагают изменение состояния. При этом ничто не мешает сделать immutable реализацию даже этих трех паттернов.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>ООП все-таки предполагает инкапсуляцию состояния.
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект.
Ловко ты перепрыгнул. И, кстати, состояние (а точнее изменяемое состояние, просто состояние даже "чистому" ФП не протворечит) далеко не всегда приводит "побочным эффектам". Типичный пример — кеши (memoize в ФП).
ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции.
Утверждение нуждается в доказательствах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Курилка, Вы писали:
К>Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
А дальше есть два пути — либо закрывать глаза на то, что изменяемое состояние существует объективно, как это делают некоторые апологеты чистого ФП, либо воспринимать его как неизбежное зло и работать в направлении по его минимизации. Например, вводя механизмы ограничений на состояния.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
T>Я вообще не понимаю, саму суть такой идеологии. Возьмем объекты окружающего мира: человек, компьютер, машина, животное. T>Все они имеют внутренние состояния и память и в этом их преимущество. "выворачивать наизнанку" что бы видеть внутреннее T>состояние объекта это нормально? да и зачем?
Смотря что проектировать.
ООП по сути является средствами проектирования некоторого неживого автомата с фиксированой структурой. Чтобы хоть както сделать его полезным и модифицируемым для окружающих, придумали модное слово полиморфизм. Если не вдаваться в детали, если вы вытяните из своих старых жигулей карбюратор и вставите точно такой же но сделаный в китае и улучшеной конструкции, это и есть полиморфизм. Если выймите в салоне магнитолу и вставите точно такую же но с двд проигрывателем, то это тоже будет полиморфизм. Разработчик оставил вам "заглушки" для быстрой подмены модулей, но только тех которые он предусмотрел
С одной стороны это гибкость, но с другой где гарантия что вам не понадобится модифицировать в автомате то, что не предусмотрел разработчик ? Прийдется брать напильничек и выпиливать новый цилиндр в моторе жигулей старой модификации
Но в большинстве случаев ООП диагнозы неутешительны. Новый цилиндр нельзя поставить вместо старого, архитектор жигулей не предусмотрел. Проще собрать новое, свое жигули
Вообщем-то "живые" организмы работают несколько по другому и отличаются тем, что для их допила нужно гораздо меньше.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, AndrewVK, Вы писали:
ВВ>>>>ООП все-таки предполагает инкапсуляцию состояния. ВВ>>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. AVK>Ловко ты перепрыгнул. И, кстати, состояние (а точнее изменяемое состояние, просто состояние даже "чистому" ФП не протворечит) далеко не всегда приводит "побочным эффектам". Типичный пример — кеши (memoize в ФП).
ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста. А скрытое от пользователя изменение состояния — это и есть побочный эффект. Как оно может не приводить-то? То, что инкапсуляция состояния в ФП есть — факт. Другой вопрос — почему оно там есть и с какими целями появилось.
Важнее то, что ФП и ООП предполагают разный подход к дизайну. ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч.
Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты.
С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек. Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом. Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя. Детальки — это, разумеется, функции.
А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП.
Здравствуйте, mrTwister, Вы писали:
ВВ>>ООП все-таки предполагает инкапсуляцию состояния. T>Во-первых, не только инкапсуляцию состояния, но и инкапсуляцию поведения. Ни то, ни другое не противоречит ФП. Проблемы будут только с изменением состояния.
Речь была именно про изменяемое состояние.
T>При этом ООП не заставляет тебя использование изменяемого состояния. Рассмотрим, например каталог ООП паттернов ГОФ: T>Abstract Factory T>1) Builder T>2) Factory Method T>3) Prototype T>4) Singleton T>5) Adapter T>6) Bridge T>7) Composite T>8) Decorator T>9) Facade T>10) Flyweight T>11) Proxy T>12) Chain of responsibility T>13) Command T>14) Interpreter T>15) Iterator T>16) Mediator T>17) Memento T>18) Observer T>19) State T>20) Strategy T>21) Template method T>22) Visitor T>Из всех этих паттернов только Builder, Iterator и State в классической реализации предполагают изменение состояния. При этом ничто не мешает сделать immutable реализацию даже этих трех паттернов.
Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие. Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста.
А теперь возвращаемся к твоему исходному утверждению — если туда подставить изменяемое состояние, то оно уже несколько не так звучит, не находишь?
ВВ> А скрытое от пользователя изменение состояния — это и есть побочный эффект.
Не всегда
ВВ> Как оно может не приводить-то?
Пример я привел.
ВВ>Важнее то, что ФП и ООП предполагают разный подход к дизайну.
Разный. Но ортогональный, а не противоположный. Это важно.
ВВ> ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч.
Ничего не понял. Какие, нафик, кирпичи?
ВВ>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт.
Это называется полиморфизм. В ФП языках тоже бывает. Функциональный тип, собственно, это оно и есть. ООП в этом плане отличается тем, что позволяет создавать полиморфную иерархию. Но ФП это никак не противоречит.
ВВ> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты.
Крайне спорный вывод, требующий доказательств.
ВВ>С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек.
Опять ничего не понял. Прежде чем приводить аналогии, попробуй пояснить свою мысль на предмете обсуждения.
ВВ> Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом.
Кирпичи тоже
ВВ> Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя.
В ООП тоже так можно. Это зависит от дизайна конкретной программы, а не от способа декомпозиции.
ВВ>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП.
Опять же крайне спорно и бездоказательно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Речь была именно про изменяемое состояние.
Изменяемое состояние допустимо в ООП, но необязательно.
ВВ>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие.
Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
ВВ>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников".
Вопросы к GoF, Фаулеру и пр.?
Здравствуйте, PC_2, Вы писали:
PC_>Смотря что проектировать. PC_>ООП по сути является средствами проектирования некоторого неживого автомата с фиксированой структурой. Чтобы хоть както сделать его полезным и модифицируемым для окружающих, придумали модное слово полиморфизм. Если не вдаваться в детали, если вы вытяните из своих старых жигулей карбюратор и вставите точно такой же но сделаный в китае и улучшеной конструкции, это и есть полиморфизм. Если выймите в салоне магнитолу и вставите точно такую же но с двд проигрывателем, то это тоже будет полиморфизм. Разработчик оставил вам "заглушки" для быстрой подмены модулей, но только тех которые он предусмотрел
PC_>С одной стороны это гибкость, но с другой где гарантия что вам не понадобится модифицировать в автомате то, что не предусмотрел разработчик ? Прийдется брать напильничек и выпиливать новый цилиндр в моторе жигулей старой модификации PC_>Но в большинстве случаев ООП диагнозы неутешительны. Новый цилиндр нельзя поставить вместо старого, архитектор жигулей не предусмотрел. Проще собрать новое, свое жигули
PC_>Вообщем-то "живые" организмы работают несколько по другому и отличаются тем, что для их допила нужно гораздо меньше.
ООП не требует фиксированности структуры. Где такие ограничения?
Объект вполне может быть динамическим.
А полиморфизм не модное слово, а удобное средство.
А что, часто приходится ставить неподходящий двигатель в машину? Такого не встречал.
Вряд ли пользователь класса окажется более продвинутым в его работе чем сам создатель
этого класса (тут нужны и чертежи и идея, лежащая за ним, которые не прописаны в конструкции).
Да и вообще, если разобраться, то есть время жизни в том числе жигулей. После его завершения
жигули действительно можно отправлять тем, кто будет что то выпиливать, а зачастую на свалку.
Собственно с машиной Вы ничего другого и не придумаете, кроме как предусмотренные и стандартизированные
комплектующие.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
К>>Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
AVK>А дальше есть два пути — либо закрывать глаза на то, что изменяемое состояние существует объективно, как это делают некоторые апологеты чистого ФП, либо воспринимать его как неизбежное зло и работать в направлении по его минимизации. Например, вводя механизмы ограничений на состояния.
Это какие-то апологеты в вакууме получаются. По-моему реально 2 других пути выходит: выносить ограничения в систему типов (монады и ун. типы) или "покласть" как в эрланге/мл/лиспах и др.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
ВВ>С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек. Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом. Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя. Детальки — это, разумеется, функции.
Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой
информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то
"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие.
T>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
Естетсвенно что в ФП аналогичные вещи основаны на функциональной декомпозиции.
ВВ>>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников". T>Вопросы к GoF, Фаулеру и пр.?
Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется.
?
.
