Здравствуйте, AndrewVK, Вы писали:
ВВ>>ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста. AVK>А теперь возвращаемся к твоему исходному утверждению — если туда подставить изменяемое состояние, то оно уже несколько не так звучит, не находишь?
Ничего не понял. Что не так звучит?
ВВ>>Важнее то, что ФП и ООП предполагают разный подход к дизайну. AVK>Разный. Но ортогональный, а не противоположный. Это важно.
Может, и не противоположный, но взаимоисключающий.
ВВ>> ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч. AVK>Ничего не понял. Какие, нафик, кирпичи?
Все очень просто. В ООП и ФП разные принципы декомпозиции. В ООП ты мыслишь в категориях *сущностей* и их поведения, отношений между ними и пр. Производя декомпозицию, ты выделяешь новые виды сущностей.
В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
ВВ>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>Это называется полиморфизм. В ФП языках тоже бывает.
Это ты к чему? Ну да, частный случай полиморфизма, который прекрасно себя чувствует и без всякого ООП.
AVK>Функциональный тип, собственно, это оно и есть. ООП в этом плане отличается тем, что позволяет создавать полиморфную иерархию. Но ФП это никак не противоречит.
Причем тут функциональный тип?
Полиморфную иерархию можно создать и через алгебраические типы.
ВВ>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>Крайне спорный вывод, требующий доказательств.
Что тебе кажется спорным? Может, я неясно выразился? Любая программа так или иначе растет количественно. Идеал ООП — чтобы количественный рост не переходил в качественный. Т.е. у нас как был раньше фиксированный набор контрактов — он так и остается. В реальности же реализации объектов меняются, появляются новые объекты и пр.
ВВ>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>Опять же крайне спорно и бездоказательно.
Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП?
Здравствуйте, tripol, Вы писали:
T>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Здравствуйте, samius, Вы писали:
T>>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции. S>Естетсвенно что в ФП аналогичные вещи основаны на функциональной декомпозиции.
Ну да.
S>Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется.
И опять да. Я, таким образом, лишь обратил внимание, что подавляющее большинство приемов объектно-ориентированной декомпозиции не предусматривают изменяемое состояние. Соответственно, утверждение, что ООП — это "один большой побочный эффект" является ложным.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Речь была именно про изменяемое состояние. T>Изменяемое состояние допустимо в ООП, но необязательно.
Угу, риск для жизни присутствует, но это не значит, что вы обязательно сдохнете.
Это уже не важно, обязательно или необязательно. На практике — оно неизбежно. Но спорить не буду. Раз оно в принципе допустимо — то в корне меняет весь подход при разработке.
ВВ>>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие. T>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
Разве? Ну где тут необходимость в объектной декомпозиции на самом-то деле?
Попробуйте вот интереса ради реализовать эти паттерны, скажем, на F#. Без классов, разумеется.
ВВ>>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников". T>Вопросы к GoF, Фаулеру и пр.?
Фаулера не трожьте
А у ГОФа, да, не мешало бы спросить, из каких лиспов источников они свои паттерны позаимствовали.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется. T>И опять да. Я, таким образом, лишь обратил внимание, что подавляющее большинство приемов объектно-ориентированной декомпозиции не предусматривают изменяемое состояние. Соответственно, утверждение, что ООП — это "один большой побочный эффект" является ложным.
В абсолютном плане — да, ложным. Но относительно 99% ООП оно справедливо.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>Ага, например для "тупого" парсера...
А кто говорит, что парсер умен? Это просто некий автомат, который выполняет то, для
чего предназначен.
Где обучаемость, способность запоминать и воспроизводить информацию?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>Ага, например для "тупого" парсера...
И даже парсеру требуется помнить состояние для его работы, собственно
вызов функции это тоже "запомнить" состояние, поскольку запоминается
адрес вызвавшей функции в стеке...
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, tripol, Вы писали:
T>>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>>Ага, например для "тупого" парсера...
T>А кто говорит, что парсер умен? Это просто некий автомат, который выполняет то, для T>чего предназначен.
Много чего выполняет то для чего предназначено...
T>Где обучаемость, способность запоминать и воспроизводить информацию?
А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Ага, например для "тупого" парсера...
T>И даже парсеру требуется помнить состояние для его работы, собственно T>вызов функции это тоже "запомнить" состояние, поскольку запоминается T>адрес вызвавшей функции в стеке...
Здравствуйте, samius, Вы писали:
T>>Где обучаемость, способность запоминать и воспроизводить информацию? S>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
Проблемы в том, что обучение это побочный эффект в ФП.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Где обучаемость, способность запоминать и воспроизводить информацию? S>>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
T>Проблемы в том, что обучение это побочный эффект в ФП.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
S>>>Ага, например для "тупого" парсера...
T>>И даже парсеру требуется помнить состояние для его работы, собственно T>>вызов функции это тоже "запомнить" состояние, поскольку запоминается T>>адрес вызвавшей функции в стеке...
S>За многоточием вывод о невозможности ФП?
Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций.
Можно сказать, что выполнение функции это то же состояние.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
T>>>>Где обучаемость, способность запоминать и воспроизводить информацию? S>>>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
T>>Проблемы в том, что обучение это побочный эффект в ФП.
S>Чюш
Здравствуйте, tripol, Вы писали:
T>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Откуда такие предрассудки?
Во-первых, с чего вы взяли, что парадигма языка программирования должна моделировать объекты реального мира — деревья, людей, кошек с собачками? По мне так сама эта идея довольно бредовая.
Наконец с чего это отсутствие побочных эффектов должно приводить к... гм... "потере интекллекта"? На ФЯ нельзя писать программы, которые занимаются "интеллектуальной обработкой"? По-моему это смешно.
Из того, что вы вместо класса Туалет с методом Сходить, сделаете функцию Сходить_В_Туалет, которая в качестве параметра будет принимать структуру, описывающую туалет, а возвращать... ну не будем об этом... и не сохранять результаты своей деятельности "по месту", в качестве "состояния", то данная функция, поверьте, совсем не потеряет в интеллектуальности.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
ВВ>Откуда такие предрассудки? ВВ>Во-первых, с чего вы взяли, что парадигма языка программирования должна моделировать объекты реального мира — деревья, людей, кошек с собачками? По мне так сама эта идея довольно бредовая.
Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки
используется в жигулях для ... чего нибудь".
ВВ>Наконец с чего это отсутствие побочных эффектов должно приводить к... гм... "потере интекллекта"? На ФЯ нельзя писать программы, которые занимаются "интеллектуальной обработкой"? По-моему это смешно.
Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП?
ВВ>Из того, что вы вместо класса Туалет с методом Сходить, сделаете функцию Сходить_В_Туалет,
Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
Здравствуйте, tripol, Вы писали:
T>Ага, запомнить, значит скрытое состояние?
Нету абсолютно "чистых" ФП это бессмысленно.
Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>Где обучаемость, способность запоминать и воспроизводить информацию?
FR>В прологе конечно.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>Ага, запомнить, значит скрытое состояние?
FR>Нету абсолютно "чистых" ФП это бессмысленно. FR>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>За многоточием вывод о невозможности ФП?
T>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>Можно сказать, что выполнение функции это то же состояние.
Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
Ну да, частный случай полиморфизма, который прекрасно себя чувствует и без всякого ООП. 
