Здравствуйте, Mr.Cat, Вы писали:
MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Все-таки классическое процедурное на порядок "беднее".
Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн.
AVK>Нет. В ФП я мыслю категориями вычисляемых функций. Функция не есть действие, в отличие от активного действия функция пассивна. Активная функция это уже с реактивным программированием связано, где верхушка реактивной цепочки обычно активная, но там вылазит таки соответствующая монада, которая, как ты утверждаешь, нифига не ФП.
Брр, сейчас ты уже начинаешь спорить, т.к. тебе термин действие не понравился? Извини, придется тебе с этим смириться. Для меня "Развернуть список" — это именно что действие. Впрочем, можно использовать нейтральный термин "функция".
Рассуждения об активности/пассивности функций я, извини, не понял. Это о чем вообще?
ВВ>> Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. AVK>А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?
Про итераторы я же говорил — их в ФП нет
Замыкания. А что, ты считаешь замыкания смешивают данные и функции? Может лучше издалека начнем?
Зачем нужны замыкания и на что они, собственно, замыкаются-то?
ВВ>> Есть данные — отдельно. Есть операции — отдельно. AVK>Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.
Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом. Но тут и в лес ходить далеко не надо. Даже такой вот код:
function foo() {
let x = 1
}
уже будет меня опровергать
Карринг — средство создания новой функции из имеющей. Аналогичный композиции. Кстати, композиция тоже вполне "меня опровергает", чем функции не данные?
Смешение данных и операций — это то, что мы наблюдаем в ООП. Когда операции становятся поведением объекта, т.е. фактически его сущностной характеристикой и как следствие — неразрывными от этого объекта. А карринг, частичное применение и прочие механизмы просто помогают тебе специфицировать обобщенные функции, они от этого не становятся частью чьего-то поведения. Никаких "классов" у нас не появляется. И данные остаются просто данными, а не чьим-то "состоянием".
ВВ>> Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр. AVK>А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.
Все правильно, только это уже не ООП. Все вот эти сентенции в стиле "наследование" есть рут ов олл ивил, композиция хорошо, как раз и показывают некоторую усталость от традиционного ООП.
Ты когда объекты комбинируешь, то с т.з. ООП делаешь, вообще говоря, полную хрень. А именно нарушаешь тот самый "иерархический ОО полиморфизм", ибо объекты-то ты скомбинировал, а вот их контракты увы не скомбинируются.
При этом ты, собственно, начинаешь писать в стиле, куда более близком к ФП, чем к ООП. Если по каким-то идеологическим причинам, тебе больше нравится называть это по-прежнему ООП, то я-то абсолютно не против. Но сабжа это никак не отменяет.
ВВ>>>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>>>Это называется полиморфизм. В ФП языках тоже бывает. ВВ>>Это ты к чему? AVK>Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.
Полиморфизм есть такая особенность, которая присуща чуть ли не всем парадигмам. Речь не о полиморфизме вообще, а о том, какими именно средствами он достигается в ООП. И вот эти средства — а не сам абстрактный полиморфизм — не очень-то с ФП дружат. Как и с отрекламированной тобой композицией, кстати.
ВВ>>Причем тут функциональный тип? AVK>Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.
Не понял, честно говоря. Функциональный тип — ну это просто функция. О каком "динамическом полиморфизме" речь?
ВВ>>Полиморфную иерархию можно создать и через алгебраические типы. AVK>Верно. Отсюда простое следствие — полиморфизм никак не может служить отличием ООП от ФП.
Следствие отсюда еще проще — речь не о полиморфизме совсем.
ВВ>>>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>>>Крайне спорный вывод, требующий доказательств. ВВ>>Что тебе кажется спорным? AVK>Твое утверждение, которое я, кстати, процитировал. ВВ>>Любая программа так или иначе растет количественно. AVK>Растет. В том числе и функциональная. ВВ>> Идеал ООП — чтобы количественный рост не переходил в качественный. AVK>И идеал ФП. ВВ>>В реальности же реализации объектов меняются, появляются новые объекты и пр. AVK>И?
Если ты с этим согласен, то непонятно, почему мое предыдущее утверждение показалось тебе спорным.
AVK>Я по прежнему не вижу принципиальных отличий от ФП.
Странно. Ну начнем с того, что в ФП никаких объектов нет. Есть четкое разделение на функции и данные. Полиморфизм в стиле ООП невозможен в принципе — например, те же алгребраические типы хоть и предоставляют "иерархический" полиморфизм, но при этом являются принципиально "закрытыми". Попробуй добавить новую продукцию в АДТ — тебе придется переделывать *все* матчи, ибо они тут же протухнут.
Ну не знаю, мне правда надо дальше продолжать?
ВВ>>>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>>>Опять же крайне спорно и бездоказательно. ВВ>>Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП? AVK>Например с того, что появились и широко используются они именно в функциональных языках для решения проблем, связанных с неспособностью чистых функциональных языков работать с изменяемым состоянием.
Они появились в функциональных языках, потому что абсолютно чистый функциональный язык без всех этих костылей есть единорог, не имеющий никакого практического применения. Это факт, с которым спорить невозможно. Однако нужны они именно для этого. Выводить те же монады в ранг каких характерных функциональных фишек, мне кажется, неправильно. Монады нужны в том же несчастном Хаскеле чтобы был хоть какой-то способ задать порядок операций. Но суть Хаскеля не в том, что он позволяет "задавать порядок", а как раз в прямо противоположном.
Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах.
Здравствуйте, samius, Вы писали:
S>А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко.
Мировая тенденция как раз движется сейчас в этом направлении с распространением многоядерных процессоров.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали: ВВ>>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр. MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Можно, наверное, и так сказать. И не вижу тут ничего плохого
С другой стороны "набор паттернов в рамках настоящих парадигм" — какая-то уж очень обтекаемая формулировка. При желании и ООП так можно припечатать.
Здравствуйте, PC_2, Вы писали:
PC_>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. PC_>Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
Мне это напоминает: "Хреновому танцору и яйца мешают", не обижайтесь, но отказываться от переменных или данных
как таковых из-за глобальных переменных — это глупо.
Здравствуйте, tripol, Вы писали:
T>Улыбочкой не отделаетесь. ООП может быть динамическим.
только в местах предусмотренных архитектором обьекта.
А архитектор не может все предусмотреть, также как автоваз не предусматривает винта вертолета, крыльев самолета или гусенец трактора.
А вот в природе такое встречается сплошь и рядом, когда структура обьекта видоизменяется довольно серьезно. Это истинно полиморфные обьекты, а не псевдо-полиморфизм с участками подменяемого кода в основном алгоритме
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, tripol, Вы писали:
S>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
T>Конечно, исходя из утопии, что бы она не была утопичной, ее необходимо "облегчить" (вводим что T>то, что является состоянием, но таковым не называется).
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
T>Конечно, исходя из утопии, что бы она не была утопичной, ее необходимо "облегчить" (вводим что T>то, что является состоянием, но таковым не называется).
Ну я о том и говорю, что не приблизишься. Значит изгоняешь демонов.
T>"математические" проникновения в программирование считаю несуразным.
Это твои личные проблемы.
Здравствуйте, FR, Вы писали: FR>Все-таки классическое процедурное на порядок "беднее". FR>Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн.
А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко. T>Мировая тенденция как раз движется сейчас в этом направлении с распространением многоядерных процессоров.
Я согласен с тем, что логично было бы чтобы она двигалась в этом направлении. И наверное кое-кто все-таки движется. Но вот называть эту тенденцию мировой наверное рано.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, PC_2, Вы писали:
PC_>>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. PC_>>Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
T>Мне это напоминает: "Хреновому танцору и яйца мешают", не обижайтесь, но отказываться от переменных или данных T>как таковых из-за глобальных переменных — это глупо.
я не обижаюсь, в среде некоторых индивидуумов часто ходит мнение о кривости рук чужих и исключительной ровности своих Обычно их эта мысль одолевает как раз когда очередная ООП подходит медленно но верно к своему серьезному переписыванию Чего уж греха таить.
А вообще новоиспеченного программиста в проект с ООП нужно пускать по хорошему только после прочтения двух-трех серьезных книг по рефакторингу
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Воронков Василий, Вы писали:
IT>>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
ВВ>Честно говоря, непротиворечивость ООП и ФП мне кажется несколько сомнительной. ООП все-таки предполагает инкапсуляцию состояния.
И?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PC_2, Вы писали:
PC_>я не обижаюсь, в среде некоторых индивидуумов часто ходит мнение о кривости рук чужих и исключительной ровности своих Обычно их эта мысль одолевает как раз когда очередная ООП подходит медленно но верно к своему серьезному переписыванию Чего уж греха таить.
А что ФП программы не подходят к переписыванию?
PC_>А вообще новоиспеченного программиста в проект с ООП нужно пускать по хорошему только после прочтения двух-трех серьезных книг по рефакторингу
А вообще новоиспеченного программиста лучше в любой проект не пускать, пока проект не поделен на практически независимые части.
Здравствуйте, Mr.Cat, Вы писали:
FR>>Все-таки классическое процедурное на порядок "беднее". FR>>Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн. MC>А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?
Не напомнишь?
Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования"
Здравствуйте, tripol, Вы писали:
T>А что ФП программы не подходят к переписыванию?
Все подходят. Но одни раньше другие позже.
Зависит очень многое еще от проектирования.
И все эти штучки только метод борьбы с нарастающей непропорционально сложностью программы.
Как говорится
Программа достигает своего идеала в момент краха (с)
Разведите рассадник глобальных переменных, ООП это позволяет, в своей программе и окунитесь в дебаг с особыми извращениями. Конечно на ООП можно писать и по другому, о многом пишут в книжках по рефакторингу, по патернам и прочье. Но одни подходы дисциплинирует и как говорил ВВП "душат гадину на корню"(с), а другие только "рекомендуют" разными книжками по рефакторингу и патернам проектирования.
В любом случае еще можно прожить 50 лет с программой,
грохнуть по столу и сказать ктож так пишет, вот оно как надо !
Конечно через 50 лет оно как-то виднее будет
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Обычно их эта мысль одолевает как раз когда очередная ООП подходит медленно но верно к своему серьезному переписыванию 
Если нам не помогут, то мы тоже никого не пощадим.
