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

MC>Здравствуйте, Gaperton, Вы писали:
G>>Экземпляр параметризованного модуля ... не имеет "идентити", и объектом не является.
MC>Почему не имеет? Не помню точно, как это реализовано в эрланге, но мы бы могли считать идентичными экземпляры модулей, созданные с идентичными параметрами.

Дак если они идентичны, то как раз identity нет

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

Ф>http://citforum.ru/gazeta/165/
ООП провалилось как серебрянная пуля, универсальный ответ на все вопросы разработки.
Именно эта пропаганда и почти что религиозная вера во всемогущество, являются основным провалом.

Здравствуйте, Курилка, Вы писали:
К>Дак если они идентичны, то как раз identity нет
Впрочем, согласен. Нет у них идентичности. Но если бы была...

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

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

S>>>Скорее всего баян, но эта статья кажется мне более адекватной.

KO>>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно.

G>Ага. На эту тему мы как-то сцеплись с Джо в эрланговском мейллисте. Процессы эрланга один в один являются объектами Smalltalk 72. Просто одно и то же, без всяких натяжек.

А ссылок не осталось? Кстати, он, похоже, несколько изменил свои взгляды на ООП и его наличие в эрланге. Вот, например, пара цитат из его прошлогоднего сообщения в мейл-листе (здесь):

I now believe the following to be central to the notion of OO.

— Isolated concurrent things
— Communication through message passing
— Polymorphism

By these criteria there are actually no OO languages (nobody can do *complete* isolation) though Erlang is nearer to being OO than many other languages. And most so-called OO languages are not OO.

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

ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.

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

ВВ>>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.
S>У меня deja vu. Не напомнишь, как имитировать ФВП в чистом С?
S>Там же нет функторов, так что скрытым параметром замкнутые данные не передашь.

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

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

S>Если бы мы развивали тему дальше в рамках ООП...

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

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

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

В качестве возражения тут выдвигается мысль, что
а) изменяемое внутренее состояние объектов не есть строгая необходимость в ООП, можно писать без этого
б) изменяемое внутренее состояние допустимо в ФП(см. итераторы и проч.)

По поводу б) все очень просто — да, допустимо в качестве этакого исключения из правил. Извините, статические методы в Шарпе тоже как-то слабо с ООП соотносятся. Но использование изменяемого внутреннего состояния не есть нормальный стиль программирования в ФП.

С пунктом а) все интереснее. Интерес как раз в том, что если бы можно было привести строгие формальные причины, по которым изменяемое внутреннее состояния в ООП необходимо и неизбежно, то и спора, собственно, не было бы.

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

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

Дальше точно стоит продолжать?

ВВ>>>> В ООП у тебя функции привязаны к структурам данных всегда.
ВВ>>Твоя позиция, видимо, сводится к тому, что программирование в "функциональном стиле" ООП никак не противоречит. Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП. Полноценно писать в ФП на Шарпе практически невозможно. Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
S>Есть подозрение, что это не из-за несоместимости моделей.

Это просто ремарка о неудобстве функциональщины в Шарпе, не более того.
Приведенная лишь в силу того, что я лично, со всеми подобающими ИМХО, не считаю опыт функционального программирования в Шарпе полноценным опытом, по которому можно судить о функциональном программировании.

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

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

Не делать утверждения — это какая-то неинтересная позиция я бы сказал. У тебя нет мнения по этому вопросу?

ВВ>> Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
AVK>Ужас просто.

Ну когда сигнатура функции уходит за край экрана — то вообще да, ужас.

ВВ>>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
AVK>А я ее и не сравниваю. На прямое опровержение твоим словам, что данные и функции в ФП связать нельзя.

Я не говорил, что нельзя. Вообще само утверждение "в ФП нельзя то-то" какое-то неправильное. Что такое "в ФП нельзя"? Есть конкретные языки. В конкретных языках, которые в большинстве своем гибридные, можно практически все что угодно.

Я говорил о том, что в ООП действия и *характеристики* некоторой сущности связываются воедино, чего не делается в ФП.
Вот посмотри мой ответ Синклеру: http://rsdn.ru/forum/philosophy/3989812.1.aspx

Автор: Воронков Василий
Дата: 08.10.10

Возможно, он лучше поясняет мою мысль.

ВВ>>Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq?
AVK>"Совместимый с ФП ООП дизайн"

Не вижу в Линке ООП дизайна.

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

C>Да чтоб я так же провалился, как ООП.

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

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

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

C>>Да чтоб я так же провалился, как ООП.

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

Эт, а зарплата осталась прежней?

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

Ф>http://citforum.ru/gazeta/165/
ООП реально провалилось в современном мире. Еще 10 лет назад оно привило бал, сегодня же большая часть кода -- это PHP/JS-быдлокод. В нем ООП если и используется, то сугубо "клиентским" способом (стандартные классы со скрипом еще используем, сами же ничего объектного ни в жисть не напишем). Так что если сравнивать, грубо говоря, по количеству строк и/или модулей, то в последнее время ООП используется действительно совсем нечасто.

P.S. Кривая деградация программирования с лагом в несколько лет просто повторяет все изгибы кривой деградации образования.

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

КЛ>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.

По моему скорее наоборот.

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

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

function Combine(f, h)
{
  return new fuction(x)
  {
    return f(h(x));
  }
}

Как её изобразить без замыканий?

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

S>

S>function Combine(f, h)
S>{
S>  return new fuction(x)
S>  {
S>    return f(h(x));
S>  }
S>}
S>

S>Как её изобразить без замыканий?

Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.

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

ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.

Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)

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

ВВ>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
К>Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)

Бррр, че сказать-то хотел? Обе функции есть частный случай ФВП, не более того. И Sort — ФВП ничуть не в меньшей степени, чем Combine, при этом замыканий не требует.

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

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

ВВ>>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
К>>Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)

ВВ>Бррр, че сказать-то хотел? Обе функции есть частный случай ФВП, не более того. И Sort — ФВП ничуть не в меньшей степени, чем Combine, при этом замыканий не требует.

Тебе говорят про "first class citizen в компиляторе", а ты показываешь некий недо-citizen

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

К>Тебе говорят про "first class citizen в компиляторе", а ты показываешь некий недо-citizen

Речь была о возможности имитации вообще-то. Вообще говоря этот самый Combine — костыли еще те, а не "first class citizen в компиляторе". Композиция в нормальном ФЯ делается в поинт-фри стиле с помощью трех букв и двух знаков препинания

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

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

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

ВВ>С пунктом а) все интереснее. Интерес как раз в том, что если бы можно было привести строгие формальные причины, по которым изменяемое внутреннее состояния в ООП необходимо и неизбежно, то и спора, собственно, не было бы.

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

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

ВВ>Приведенная лишь в силу того, что я лично, со всеми подобающими ИМХО, не считаю опыт функционального программирования в Шарпе полноценным опытом, по которому можно судить о функциональном программировании.

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


ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
Всё как раз наоборот: в частном случае будет твоя Sort. А в общем случае будет в том числе и такая, как у меня.