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

MC>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.

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

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

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

И о какой же сути речь? Пока я лишь вижу, что ты выдумываешь какие-то понятия, которые видимо одному тебе и понятны.
Сначала функция не действия, теперь она "пассивна". Откуда ты набрался этого? Чистая функция в ФП не менее "активна", чем любая грязная функция. Ее можно вызвать, она может вызвать сама, ее можно передавать в качестве параметра, комбинировать с другими ф-циями и пр.

ВВ>>Замыкания. А что, ты считаешь замыкания смешивают данные и функции?
AVK>Бе-з малейшего сомнения. В этом их смысл.
ВВ>>Зачем нужны замыкания и на что они, собственно, замыкаются-то?
AVK>Не имеет отношения к обсуждаемому вопросу.

Эээ, вот честно пытаюсь понять твою логику. Замыкания ты вспомнил сам, утверждая, с целью опровергнуть мою точку зрения, что они "смешивают данные и функции". Однако на что происходит замыкания ты считаешь не имеющим отношения к обсуждаемому вопросу. Я правильно понял?

ВВ>>Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом.
AVK>Не надо никакого буквализма. Сама суть процесса карринга — добавление данных к функции.

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

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

Слушай, давай ты не будешь уходить в ту же степь, что и товарищ tripol в этой теме, который уже практически доказал, что функциональное программирование невозможно, т.к. состояние на стеке — это тоже "скрытое" состояние, которое при этом совершенно не видно снаружи. И в отличие от каррирования, для которого существует обратная процедура под названием декаррирование, ты уж тут точно снаружи ничего не увидишь.
Тебе вот реально до подобной демагогии остался один шаг.

У всего есть какие-то границы на самом деле. Да на самом деле любая функция инкапсулирует свое состояния, и это состояние увидеть снаружи нельзя. Тут карринг вообще не причем. Как и ФП прочем. По этой причине в свое время процедурное программирование изобрели. Как раз для того, чтобы функции/подпрограммы и проч. *инкапсулировали* свое состояние. Ясен перец, что инкапсуляции в ООП не на пустом месте выросла — а из того самого, старого доброго процедурного программирования. И, естественно, тут можно провести параллели. Возникает только вопрос — на фига?

В реальности же, в реальных ООП приложениях, это самое ООП начинает инкапсулировать самые настоящие побочные эффекты, чего ФП как раз не делает. А приводить примеры всякой хрени, вроде генераторов, мне нужно. Потому что, во-первых, чистых ФЯ не существует, кроме совсем уж эзотерических. А во-вторых — ФЯ все же довольно старые языки, и в них дебютировали многие концепции, которые, собственно, развитием идей ФП ни в каком смысле не являются, а являются скорее попыткой примирить ФЯ с реальными практическими задачами.

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

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

ВВ>>А карринг, частичное применение
AVK>Карринг это и есть частичное применение.

Нет

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

Опять масло масляное. У ф-ции и так есть состояние. Карринг — это именно специализация. Очень простая мысль, но ты ее понять не хочешь. Из-за того, что функция каррируется ничего катастрофического не происходит. Она не начинает ни с того ни с сего плодить побочные эффекты.

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

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

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

Это как раз тот же самый вопрос.

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

Применялась всегда... и что? В ФП есть много вещей, которые "применялись всегда", но при этом к самой концепции ФП никакого отношения не имеют. А во многих ОО-языках "применяются всегда" и традиционные приемы процедурного программирования. Применяются, ага. Но частью ООП они от этого не становятся.
Ты тут мои "пседоаксиомы" критикуешь, а сам же ты вообще ничего пытаешься обосновать. И аксиомы я как раз вижу у тебя. Композиция. Всегда применялись. Неотъемлемая часть ООП. А если все же подумать немного? Почему это она часть ООП, каким местом она к нему относится? И второй, кстати, не менее интересный вопрос — а почему она всегда применялась-то?

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

Ну да, правильно. Существует другой механизм. ООП называется.

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

О, как. Т.е. композиция — один из столпов ООП, а к ФП уже ни сном ни духом. ООП на нее авторские права что ли зарегистрировал? Вот это уже правда смешно.

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

Я уже говорил. Очень простые мысли. Практика ООП приводит к тому, что:

— Структуры данных и функции слепливаются воедино и именуются "классами".
— В качестве одного из следствий этого мы получаем не просто инкапсуляцию состояния, а инкапсуляцию побочных эффектов.

И первое, и второе весьма затрудняют программирование в ФП-стиле.

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

О проблемах тут речи вообще не было. Так что тему лучше действительно не переключать.

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

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

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

О, боже, ну причем тут классы типов? Кто тут из нас с темы соскальзывает? Классы типов в том же хаскеле были придуманы, чтобы обойти ограничения, придуманные в хаскеле. Как тут это может помочь — я не понимаю.

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

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

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

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

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

FR>Все-таки Василий, как уже отметили выше любит сужать функциональщину.

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

Более того, могу сказать, что как только люди перестают писать в модном ныне "ФП стиле", а начинает по-настоящему писать на каком-нибудь ФЯ, пусть хоть он и поддерживает ООП, то сразу понимают, что ООП-то им больше не нужен — и вопрос о сочетаемости вообще уже не стоит, т.к. потребности никакой в ней нет — и не нужен не потому, что он плохой или провальный, а потому что ФП просто совершенно другая концепция, позволяющая однако делать то же самое что и ООП.

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

MC>>А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?
AVK>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе.

Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.

Т.е. например интерфейс USB по сути своей неверен ? Или розетка на 220 вольт со стандартным штекером не имеет права на существование ? Мне кажется вы в чем то неправы.

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

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

T>>Улыбочкой не отделаетесь. ООП может быть динамическим.

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

PC_>А вот в природе такое встречается сплошь и рядом, когда структура обьекта видоизменяется довольно серьезно. Это истинно полиморфные обьекты, а не псевдо-полиморфизм с участками подменяемого кода в основном алгоритме

Исходя из данного контекста , грамотный архитектор предусмотрит инткрфейс отвечающий за определенную ФУНкциональность. В примере выше это класс "транспортное средство" ответственностью которого будет переправить из одной точки в другую.

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

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

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

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

А тут кто то доказательства доказывает ? Я думал просто на примере пытаются продемонстрировать мысль ?и

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

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

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

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

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

M>А тут кто то доказательства доказывает ? Я думал просто на примере пытаются продемонстрировать мысль ?и

По умолчанию демонстрация "на примере" неверна. Надо доказать что пример адекватный.

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

G>По умолчанию демонстрация "на примере" неверна. Надо доказать что пример адекватный.

Вы ошибаетесь. Пример нужен для демонстрации хода мысли. Предьявлять какие либо требования к собеседнику это абсурд.

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

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

G>>По умолчанию демонстрация "на примере" неверна. Надо доказать что пример адекватный.

M>Вы ошибаетесь.
Да ну?

M>Пример нужен для демонстрации хода мысли.
Для демонстрации хода мысли можно продемонстрировать ход мысли.

M>Предьявлять какие либо требования к собеседнику это абсурд.
Счегобы?

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

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

M>>Пример нужен для демонстрации хода мысли.
G>Для демонстрации хода мысли можно продемонстрировать ход мысли.

Пример на аналогии и является такой демонстрацией.

M>>Предьявлять какие либо требования к собеседнику это абсурд.
G>Счегобы?

С того что если вы к себе предявляете одни требования а к собеседнику другие , диалог получится малопродуктивным (и это я тоже доказывать не собираюсь).

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

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

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

M>>>Пример нужен для демонстрации хода мысли.
G>>Для демонстрации хода мысли можно продемонстрировать ход мысли.
M>Пример на аналогии и является такой демонстрацией.
Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.

M>>>Предьявлять какие либо требования к собеседнику это абсурд.
G>>Счегобы?
M>С того что если вы к себе предявляете одни требования а к собеседнику другие , диалог получится малопродуктивным (и это я тоже доказывать не собираюсь).
Я аналогиями не пользуюсь.

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

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

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

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

M>>>>Пример нужен для демонстрации хода мысли.
G>>>Для демонстрации хода мысли можно продемонстрировать ход мысли.
M>>Пример на аналогии и является такой демонстрацией.
G>Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.

Докажите что стоит , иначе предложение выше можно считать бредом.

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

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

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

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

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

M>>>>>Пример нужен для демонстрации хода мысли.
G>>>>Для демонстрации хода мысли можно продемонстрировать ход мысли.
M>>>Пример на аналогии и является такой демонстрацией.
G>>Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.

M>Докажите что стоит , иначе предложение выше можно считать бредом.
От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.

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

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

M>>Докажите что стоит , иначе предложение выше можно считать бредом.
G>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.

Докажете ваше утверждение выше, иначе это бред по умолчанию.

P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.

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

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

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

M>>>Докажите что стоит , иначе предложение выше можно считать бредом.
G>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.

M>Докажете ваше утверждение выше, иначе это бред по умолчанию.
Заклинило?

M>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.
Угадай что надо сделать для выделенного?

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

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

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

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

M>>>>Докажите что стоит , иначе предложение выше можно считать бредом.
G>>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.

M>>Докажете ваше утверждение выше, иначе это бред по умолчанию.
G> Заклинило?

Нет , демонстрирую абсурдность твоих утверждений на примере. Думал что ты догадаешься.


M>>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.
G>Угадай что надо сделать для выделенного?

Много чего можно сделать , а угадывать что ты тут себе напридумывал мне нет мотивации.

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

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

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

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

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

M>>>>>Докажите что стоит , иначе предложение выше можно считать бредом.
G>>>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.

M>>>Докажете ваше утверждение выше, иначе это бред по умолчанию.
G>> Заклинило?

M>Нет , демонстрирую абсурдность твоих утверждений на примере. Думал что ты догадаешься.

Я говорил про аналогии, а ты фигню несешь.

M>>>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.
G>>Угадай что надо сделать для выделенного?
M>Много чего можно сделать , а угадывать что ты тут себе напридумывал мне нет мотивации.
Ясно, слился.

Надеюсь что ты понимаешь , в таком тупом ключе и "уровнем" общения , меня диалог не привлекает.

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

PC_>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
На первом. И с огромным отрывом.
goto пакостит только внутри функции, а глобальные переменные по всей программе.
Что называется почувствуйте разницу.