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

AVK>Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.

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

AVK>Только вот твои качественно-экспертные оценки лично меня нисколечко не убеждают.

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

K>>1) — абстракции в ООП слабенькие и протекающие, но это можно исправить
AVK>Субъективно

Объективно. ООП-шные абстракции 1) теряют информацию 2) легко "вскрываются" штатными средствами. При этом первое диктует необходимость второго.

K>>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств
AVK>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

Объективно. Формальное описание нетривиального ООП — это высшая точка TAPL — самая сложная часть требующая (почти) всех знаний приобретаемых в ходе этого курса. Забавный факт: это формальное описание оказалось достаточно мозгоразрывающим даже для Пирса (самого настоящего, а не форумного эксперта по обсуждаемому вопросу) так что он совершил ошибку, которую потом пришлось исправлять.
Это формальное описание требует F^omega_sub, которая, собственно, содержит все мозгоразрывающее из ФЯ (то, что разрывает мозги сильнее уже и языками-то не считается, а считается приф-ассистантами) + нешуточная экстра. С половиной из этих ужасов программист на ФЯ вообще не сталкивается, а с большей частью из того, с чем сталкивается — сталкивается меньшую часть времени.
Самое же обидное, что при такой сложности извлекать из этого формального описания затруднительно.

AVK>Вообще какая то игра терминами. Наследование и агрегация — основные способы комбинирования в ООП — вполне себе удобные способы комбинирования, хоть и не идеальные.

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

AVK>У чистого ФП — больше. Сигнатура функции слишком примитивна,

Это можно как-то раскрыть подробнее?

AVK>приходится даже на нижнем уровне вводить всякие подпорки типа карринга,

Почему карринг — подпорка?

AVK>туплов, АлгТД и т.п.

Туплы — это и есть АлгТД.

AVK>Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

То, что сущностей в ФП больше — голословное утверждение.

AVK>Набор функций как раз и потребовался

Вопрос в том, в чем "дополнительность сущности" набора функций по отношению к набору функций. Функция и функция — одна и та же сущность.

AVK>из-за проблем с хранением всей спецификации в сигнатурах функций.

Претензия к "автоматическому протягиванию" тайпклассов через неявный параметр — это претензия к дополнительной сущностности того же уровня, что претензия к неявному this в ООП.