Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
S>>>За многоточием вывод о невозможности ФП?
T>>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>>Можно сказать, что выполнение функции это то же состояние. S>Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
И к регистру, и к кэшу и к памяти, и к винчестеру, ко всему, что может хранить состояние.
В рамках ФП просто компьютер бы не смог работать.
Здравствуйте, tripol, Вы писали:
T>>>Где обучаемость, способность запоминать и воспроизводить информацию?
FR>>В прологе конечно.
T>И как там это организовано?
Здравствуйте, tripol, Вы писали:
FR>>Нету абсолютно "чистых" ФП это бессмысленно. FR>>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
T>В каких областях?
Во всех, неизолированное изменяемое состояние — зло.
Здравствуйте, tripol, Вы писали:
T>Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки T>используется в жигулях для ... чего нибудь". T>Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП? T>Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ничего не понял. Что не так звучит?
ООП все-таки предполагает инкапсуляцию состояния
ВВ>>>Важнее то, что ФП и ООП предполагают разный подход к дизайну. AVK>>Разный. Но ортогональный, а не противоположный. Это важно.
ВВ>Может, и не противоположный, но взаимоисключающий.
Докажи.
AVK>>Ничего не понял. Какие, нафик, кирпичи?
ВВ>Все очень просто. В ООП и ФП разные принципы декомпозиции.
Разные.
ВВ>В ФП ты мыслишь в категориях *действий*.
Нет. В ФП я мыслю категориями вычисляемых функций. Функция не есть действие, в отличие от активного действия функция пассивна. Активная функция это уже с реактивным программированием связано, где верхушка реактивной цепочки обычно активная, но там вылазит таки соответствующая монада, которая, как ты утверждаешь, нифига не ФП.
ВВ> Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет.
А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?
ВВ> Есть данные — отдельно. Есть операции — отдельно.
Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.
ВВ> Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.
ВВ>>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>>Это называется полиморфизм. В ФП языках тоже бывает.
ВВ>Это ты к чему?
Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.
ВВ>Причем тут функциональный тип?
Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.
ВВ>Полиморфную иерархию можно создать и через алгебраические типы.
Верно. Отсюда простое следствие — полиморфизм никак не может служить отличием ООП от ФП.
ВВ>>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>>Крайне спорный вывод, требующий доказательств.
ВВ>Что тебе кажется спорным?
Твое утверждение, которое я, кстати, процитировал.
ВВ>Любая программа так или иначе растет количественно.
Растет. В том числе и функциональная.
ВВ> Идеал ООП — чтобы количественный рост не переходил в качественный.
И идеал ФП.
ВВ>В реальности же реализации объектов меняются, появляются новые объекты и пр.
И? Я по прежнему не вижу принципиальных отличий от ФП.
ВВ>>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>>Опять же крайне спорно и бездоказательно.
ВВ>Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП?
Например с того, что появились и широко используются они именно в функциональных языках для решения проблем, связанных с неспособностью чистых функциональных языков работать с изменяемым состоянием.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>ООП не требует фиксированности структуры. Где такие ограничения? T>Объект вполне может быть динамическим.
Еще как требует
Именно архитектор задает набор интерфейсов, эвентов, публичных методов. Он жестко прописывает порядок и типы переменных для каждого внешнего вызова. Шаг вправо шаг влево программа не то что будет работать с ошибкой, она просто не скомпилируется.
Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье ... Хотя той полезной функциональности может быть совсем ничего. Поэтому деклараций всяких интерфейсов, виртуальных методов и прочья в таких программах приближается а может и привышает количество полезного кода, который собственно наконец что-то делает с примитивами
Это всеравно что, чтобы создать универсальное Жигули архитектор придумал напихать туда самых разных разьемов и интерфейсов чтобы расширять и расширять возможности Жигули
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, tripol, Вы писали:
T>>Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки T>>используется в жигулях для ... чего нибудь". T>>Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП? T>>Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
ВВ>Студент?
Здравствуйте, Воронков Василий, Вы писали: ВВ>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>>>За многоточием вывод о невозможности ФП?
T>>>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>>>Можно сказать, что выполнение функции это то же состояние. S>>Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
T>И к регистру, и к кэшу и к памяти, и к винчестеру, ко всему, что может хранить состояние. T>В рамках ФП просто компьютер бы не смог работать.
Почитай для начала что-нибудь о состояниях. Ни один функциональщик не утверждал что ФП программа может работать без изменения памяти, регистров и т.п.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
FR>>>Нету абсолютно "чистых" ФП это бессмысленно. FR>>>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
T>>В каких областях?
FR>Во всех, неизолированное изменяемое состояние — зло.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
S>Почитай для начала что-нибудь о состояниях. Ни один функциональщик не утверждал что ФП программа может работать без изменения памяти, регистров и т.п.
S>Споришь со своими догадками.
Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило.
В ООП такой утопии нет.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Споришь со своими догадками.
T>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило.
Вот и славно.
T>В ООП такой утопии нет.
А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>ООП не требует фиксированности структуры. Где такие ограничения? T>>Объект вполне может быть динамическим.
PC_>Еще как требует PC_>Именно архитектор задает набор интерфейсов, эвентов, публичных методов. Он жестко прописывает порядок и типы переменных для каждого внешнего вызова. Шаг вправо шаг влево программа не то что будет работать с ошибкой, она просто не скомпилируется.
PC_>Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье ... Хотя той полезной функциональности может быть совсем ничего. Поэтому деклараций всяких интерфейсов, виртуальных методов и прочья в таких программах приближается а может и привышает количество полезного кода, который собственно наконец что-то делает с примитивами
PC_>Это всеравно что, чтобы создать универсальное Жигули архитектор придумал напихать туда самых разных разьемов и интерфейсов чтобы расширять и расширять возможности Жигули
Что самое интересное, когда мне понадобится пятое колесо вместо четырех в Жигулях, то как всегда окажется что разьема такого то и нету среди остального хлама в программе и привет перепроэктированию программы снова, пока не появится шестое колесо
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
T>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>Вот и славно.
T>>В ООП такой утопии нет. S>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>>Вот и славно.
T>>>В ООП такой утопии нет. S>>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
T>Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Но относительно 99% ООП оно справедливо.
T>Не согласен, моя практика показывает, что при понимании того, что immutable объекты — это круто, со временем остается очень мало mutable кода.
А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>>Вот и славно.
T>>>В ООП такой утопии нет. S>>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
T>Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>ООП не требует фиксированности структуры. Где такие ограничения? T>>Объект вполне может быть динамическим.
PC_>Еще как требует
Улыбочкой не отделаетесь. ООП может быть динамическим.
PC_>Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье
Я к этому не стремлюсь, да и вообще к этому стремятся не часто. У программы есть период жизни. Перепроектировать придется
в любом случае, какая бы методология не использовалась, только в новом проекте большинство классов может остаться прежним,
а изменения коснутся только 5-того или 6-го колеса.
? А как же мозги, то же зло?
