Здравствуйте, tripol, Вы писали:

T>Здравствуйте, PC_2, Вы писали:

PC_>>Здравствуйте, tripol, Вы писали:

T>>>Вообще пятое колесо это серьезное изменение и требует перепроектирования.

PC_>>Вот ты уже начинаешь понимать, что в ООП Жигулях разве что Магнитолу хорошо менять одну за одной

T>И колеса и запчасти и вообще почти все кроме корпуса. В ООП корпус легко можно
T>выкинуть на помойку и поставить другой. Так и не услышал на счет жигули vs ФП...

На самом деле тебе нужно представлять, машина с четырьмя колесами или с пятью — разница не большая. Ты предложил перепроектировать. Это хорошо что ты понимаешь, что даже если ООП программа как ёжик в интерфейсах, пятое колесо ведет к переписыванию структуры программы с кучей времени и багов.

Что касается ФП.

Есть такой афоризм про Лисп,
Лиспер долго запрягает но быстро едет (с)

Долго запрягает потому что пока опишет тоже Жигули, прийдется описать еще один промежуточный язык. Но зато когда напишет, добавить еще одно колесо будет что-то
вроде +1 колесо и вуаля. Все конечно утрировано, но правда как всегда где-то рядом

Здравствуйте, Фукерман, Вы писали:

Ф>http://citforum.ru/gazeta/165/
Это надо занести в список капецов:
1. Венде-капец.
2. C-капец.
3. C++-капец.
4. Вот теперь ООП-капец.

ЗЫ: А мужики то не знали!

Здравствуйте, Vain, Вы писали:


Ф>>http://citforum.ru/gazeta/165/
V>Это надо занести в список капецов:
V>1. Венде-капец.
V>2. C-капец.
V>3. C++-капец.
V>4. Вот теперь ООП-капец.

Еще добавь явакапец

Здравствуйте, Фукерман, Вы писали:

Ф>http://citforum.ru/gazeta/165/

А Фукерман только масла в огонь подлил и сам только наблюдает,
как другие спорят...

Здравствуйте, PC_2, Вы писали:

PC_>На самом деле тебе нужно представлять, машина с четырьмя колесами или с пятью — разница не большая. Ты предложил перепроектировать. Это хорошо что ты понимаешь, что даже если ООП программа как ёжик в интерфейсах, пятое колесо ведет к переписыванию структуры программы с кучей времени и багов.

На самом деле пятое колесо это из ряда вон выходящее, поэтому начальный дизайн такой
смены не предвидит и правильно делает.

PC_>Что касается ФП.

PC_>Долго запрягает потому что пока опишет тоже Жигули, прийдется описать еще один промежуточный язык. Но зато когда напишет, добавить еще одно колесо будет что-то
PC_>вроде +1 колесо и вуаля. Все конечно утрировано, но правда как всегда где-то рядом

Не ну и в ООП типа можно написать "компилятор" машин, или использовать почти готовый.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, Фукерман, Вы писали:

Ф>>http://citforum.ru/gazeta/165/
V>Это надо занести в список капецов:
V>1. Венде-капец.
V>2. C-капец.
V>3. C++-капец.
V>4. Вот теперь ООП-капец.

V>ЗЫ: А мужики то не знали!

ООП не капец, поскольку его потихоньку пилят в нужном направлении.
Глобальные переменные подгребли,
талмуды по рефакторингу написали,
талмуды по паттернам — тоже написали,
сборку муссора ценой титанических усилий — сделали,
лямды и прочье — тоже потихоньку подмешивают с синтаксическим сахарком

Скоро будет мемоизация ( я вот в своем проекте хочу покрутить ).
Так что ООП жив и будет жить. То что многое из этого было еще 50 лет в ФП уже мало кого интересуют. Есть миллиард студентов и индусов, развернутая ИТ индустрия, тысячи библиотек без которых прожить уже нельзя.

Здравствуйте, Mr.Cat, Вы писали:

MC>Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.

А что такое настоящая парадигма? ООП — это тоже несколько паттернов: инкапсуляция, наследование, полиморфизм.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Брр, сейчас ты уже начинаешь спорить, т.к. тебе термин действие не понравился?

Дело не в термине, дело в сути.

ВВ>Рассуждения об активности/пассивности функций я, извини, не понял. Это о чем вообще?

Функция в ФП пассивна. Она не проявляет активности сама, ее можно только вызвать.

AVK>>А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?

ВВ>Про итераторы я же говорил — их в ФП нет

Ясно. Дальше, в принципе, можно уже не продолжать.

ВВ>Замыкания. А что, ты считаешь замыкания смешивают данные и функции?

Бе-з малейшего сомнения. В этом их смысл.

ВВ>Зачем нужны замыкания и на что они, собственно, замыкаются-то?

Не имеет отношения к обсуждаемому вопросу.

ВВ>>> Есть данные — отдельно. Есть операции — отдельно.
AVK>>Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.

ВВ>Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом.

Не надо никакого буквализма. Сама суть процесса карринга — добавление данных к функции.

ВВ>Карринг — средство создания новой функции из имеющей.

Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции.

ВВ> Аналогичный композиции. Кстати, композиция тоже вполне "меня опровергает", чем функции не данные?

Без кавычек опровергает. Но карринг в качестве примера намного лучше — прицепиться тебе не удастся к деталям, приходится просто сползать с темы.

ВВ>А карринг, частичное применение

Карринг это и есть частичное применение.

ВВ> и прочие механизмы просто помогают тебе специфицировать обобщенные функции

Это все лирика, вода на киселе. По факту карринг как раз таки подмешивает состояние к функции и именно для этого он используется в реальных программах. Конечно, выглядит это не идентично инкапсуляции в ООП, но эффект в конечном итоге очень похож.

ВВ>, они от этого не становятся частью чьего-то поведения. Никаких "классов" у нас не появляется. И данные остаются просто данными, а не чьим-то "состоянием".

Это все пустые слова без аргументов и даже логических цепочек. Все твои тирады сводятся к простому — ФП противоречит ООП, потому что ФП противоречит ООП. Доказательная сила идентична.

AVK>>А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.

ВВ>Все правильно, только это уже не ООП.

Самому не смешно?

ВВ> Все вот эти сентенции в стиле "наследование" есть рут ов олл ивил, композиция хорошо, как раз и показывают некоторую усталость от традиционного ООП.

Это другой вопрос. Не отклоняйся от темы.

ВВ>Ты когда объекты комбинируешь, то с т.з. ООП делаешь, вообще говоря, полную хрень.

Это тебе только так кажется. Композиция применялась и применяется в ООП всегда и является неотъемлемой ее частью. И твои псевдоаксиомы не соответствуют действительности и ничего не доказывают.

ВВ> А именно нарушаешь тот самый "иерархический ОО полиморфизм", ибо объекты-то ты скомбинировал, а вот их контракты увы не скомбинируются.

А почему они должны комбинироваться? Для комбинирования контрактов существует наследование контрактов, совсем другой механизм.

ВВ>При этом ты, собственно, начинаешь писать в стиле, куда более близком к ФП, чем к ООП.

Извини, это полнейшая чушь. Никакого отношения к ФП композиция не имеет. Т.е. совсем.

ВВ> Если по каким-то идеологическим причинам, тебе больше нравится называть это по-прежнему ООП, то я-то абсолютно не против. Но сабжа это никак не отменяет.

Ты не переключай тему. Ты доказывай, почему ФП противоречит ООП и с ним не совместимо. Проблемы ООП это отдельная тема, и у ФП, кстати, проблем не меньше. Проповедники серебрянных пуль идут в лес.

AVK>>Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.

ВВ>Полиморфизм есть такая особенность, которая присуща чуть ли не всем парадигмам.

Отлично. Аргумент выкидываем.

ВВ> Речь не о полиморфизме вообще, а о том, какими именно средствами он достигается в ООП.

Тривиальными.

ВВ> И вот эти средства — а не сам абстрактный полиморфизм — не очень-то с ФП дружат.

Потому что ты так сказал? У меня, к примеру, дружат. Сколько бы ты не написал подобных утверждений, твое мнение от этого не станет обоснованнее ни на миллиметр. Нужны аргументы, а не спорные продукции твоего ИМХО в голом виде.

AVK>>Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.

ВВ>Не понял, честно говоря.

Ну так подумай.

ВВ> Функциональный тип — ну это просто функция.

Нет. Функциональный тип это не функция, а ее тип. Что интереснее, у функционального типа могут быть экземпляры, как и у объекта. Дальше догадаться, где там полиморфизм, совсем не сложно.
Есть в ФП и более интересные конструкции в эту тему. Например классы типов в хаскеле.

ВВ> О каком "динамическом полиморфизме" речь?

Полиморфизм в рантайме.

ВВ>Следствие отсюда еще проще — речь не о полиморфизме совсем.

Ты первый про полиморфизм вещать начал. Я тут не причем.

ВВ>Если ты с этим согласен, то непонятно, почему мое предыдущее утверждение показалось тебе спорным.

Потому что оно несколько отличалось от того, с чем я согласен.

ВВ>Странно. Ну начнем с того, что в ФП никаких объектов нет.

И что? Не надо доказывать, что ФП это не ООП, это и так понятно. Ты докажи, что ФП противоречит ООП.

ВВ>Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах.

Вася, не надо выделять никакие сущности, тебя об этом никто не просит.

Здравствуйте, Mr.Cat, Вы писали:

MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.

Существует. Просто ФП, конечно же, намного богаче, чем Василий тут пытается рассказать.

Здравствуйте, Mr.Cat, Вы писали:

MC>А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?

ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе.

Здравствуйте, PC_2, Вы писали:

PC_>Знаешь что будет если в Жигулях попробовать поставить пятое колесо ?
PC_>Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...

Может для тебя это и новость, но доказательства по аналогии логически некорректны.

Здравствуйте, tripol, Вы писали:

T>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций.
T>Можно сказать, что выполнение функции это то же состояние.

А вот и следствие вольного обращения ВВ с терминами. Речь не просто о состоянии, а об изменяемом состоянии.

Здравствуйте, PC_2, Вы писали:

PC_>Функциональных подход например помогает избежать так называемых глобальных переменных.

Ты таки продолжаешь доставлять Нет ничего лучше студента с активной позицией по сложным вопросам программирования.

PC_>Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.

Не угадал. Бегом читать литературу по CS.

Здравствуйте, tripol, Вы писали:

T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП
T>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.

Квантор всеобщности тут явно лишний. Потому что как минимум у меня возникают.

Здравствуйте, PC_2, Вы писали:

PC_>Глобальные переменные подгребли,

К ООП не имеет отношения.

PC_>лямды и прочье — тоже потихоньку подмешивают с синтаксическим сахарком

Лямбды это точно не ООП, а та самая функциональщина.

PC_>Скоро будет мемоизация ( я вот в своем проекте хочу покрутить ).

Мемоизация в ООП не нужна, там изменяемое состояние свободно доступно и прошивать в компилятор поддержку кеширования не нужно, библиотек вполне достаточно.

PC_>Так что ООП жив и будет жить. То что многое из этого было еще 50 лет в ФП уже мало кого интересуют.

Ты, судя по всему, путаешь ООП как концепцию и мейнстрим ЯВУ.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Попробуйте вот интереса ради реализовать эти паттерны, скажем, на F#. Без классов, разумеется.

А можно на erlang?

Абстрактная фабрика

-module(af).
-export([start/3]).

% family 1
f1a(X) -> X + 1.
f1b(X) -> X - 1.
ab1(a) -> fun(X) -> f1a(X) end; ab1(b) -> fun(X) -> f1b(X) end.

% family 2
f2a(X) -> X * 2.
f2b(X) -> X / 2.
ab2(a) -> fun(X) -> f2a(X) end; ab2(b) -> fun(X) -> f2b(X) end.

% factory
get(F, X, Y) -> Q = F(X), Q(Y).

% test
start(f1, a, X) -> get(fun(X) -> ab1(X) end, a, X);
start(f1, b, X) -> get(fun(X) -> ab1(X) end, b, X);
start(f2, a, X) -> get(fun(X) -> ab2(X) end, a, X);
start(f2, b, X) -> get(fun(X) -> ab2(X) end, b, X).

Шаблонный метод, по идее , вырождается вот в такое:

-module(tm).
-export([start/2]).

% template method
tm(A, B, C, X) -> P = A(X), Q = B(P), R = C(Q).

% test
start(a, X)
    -> tm(fun(Y)->Y+1 end, fun(Y)->Y*2 end, fun(Y)->Y-1 end, X);
start(b, X)
    -> tm(fun(Y)->Y-1 end, fun(Y)->Y*2 end, fun(Y)->Y+1 end, X).

Здравствуйте, Mr.Cat, Вы писали:

FR>>Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования"
MC>Тут вот хз, я пытаюсь сгенерировать мысль в ответ тебе и Василию, но она пока не генерируется.

Все-таки Василий, как уже отметили выше любит сужать функциональщину.
Если же ее брать в том виде как она реализована в существующих языках (ML образные, потомки миранды и схемо-лиспы),
то их выразительность и возможности (не исключая и императивные) практически позволяют быть полноценной
альтернативой ООП языкам. При этом ОО вполне может и наверно остается в декомпозиции, но реализуется все
из кирпичиков которые не включают классы и объекты, а состоят из ADT (в обоих расшифровках ) ФВП с замыканиями,
и очень небольшой примеси императивщины.

Здравствуйте, Фукерман, Вы писали:

Ф>http://citforum.ru/gazeta/165/

Автор -- клинический идиот. В медицинском смысле.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, tripol, Вы писали:

T>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Можно и по делу — ты только уточни для начала что обсуждается-то. С++, улитки или ФП. И что спросить-то хотел, собственно.

T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП
T>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.

T>А если возникают, то интересно, кто и как пишет, что они возникают.

Проблемы возникают у всех. Просто одни к ним привыкли, а другие ищут способы избежать проблем.

Ты попадаешь в первую категорию.

Связность по состоянию (здесь и далее имеет ввиду наблюдаемое изменяемое состояние) делает значимым порядок вычислений. Становятся недоступными многие оптимизации, становятся сложнее рассуждения о программе. Это все ведет к увеличению количества багов. А если порядок вообще не фиксированный (многопоточность), то приходится прикладывать много усилий чтобы вычисления как-то упорядочить, чтобы это не приводило к случайным результатам.

Здравствуйте, tripol, Вы писали:

T>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>У кого выяснил-то? Проблемы возникают и часто. Возьмем хотя бы параллельное программирование. Или сложность отладки. Вернее, скажем так — жестую в ней необходимость.

T>Не знаю как в параллельном, но в мультипоточном, если проблемы, то это проблемы
T>архитектуры.
Естественно это проблемы архитектуры и вызваны они именно изменяемым состоянием.