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

С этим, конечно, спорить просто глупо.

Лично я считаю, что полновесный ООП уместен в малом числе случаев. Я вообще не припоминаю, когда последний раз я бы писал какую-то иерархию классов, кроме как для удовлетворения идиотского фреймворка.

Поэтому ООП я могу сравнить с такой фичей интересной, под названием "множественная диспетчеризация". В ООП выбор реализации метода зависит от типа первого аргумента this. Это одиночная диспатчеризация. Множественная диспатчеризация расширяет этот выбор до произвольного числа аргумнентов. В частности есть известный паттерн Визитёр, который, используя одиночную диспатчеризацию (к примеру C++, как в классической книге Четырёх) реализует двойную диспатчеризацию (ну и по аналогии можно реализовать произвольную диспатчеризацию). И там, где у языка с двойной диспатчеризацией будет очень простой код, этот самый Визитёр городит огромную кучу дополнительного кода.

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

По поводу ООП такого консенсуса нет, это я готов признать. Но своё мнение я высказал.

Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации. Также может быть полезен синтаксический сахар, для замены наследования реализаций композицией. Вот это подмножество действительно полезно и часто применимо. А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее. Вреда больше, чем пользы.

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

С этим, конечно, спорить просто глупо.

Лично я считаю, что полновесный ООП уместен в малом числе случаев. Я вообще не припоминаю, когда последний раз я бы писал какую-то иерархию классов, кроме как для удовлетворения идиотского фреймворка.

Поэтому ООП я могу сравнить с такой фичей интересной, под названием "множественная диспетчеризация". В ООП выбор реализации метода зависит от типа первого аргумента this. Это одиночная диспатчеризация. Множественная диспатчеризация расширяет этот выбор до произвольного числа аргумнентов. В частности есть известный паттерн Визитёр, который, используя одиночную диспатчеризацию (к примеру C++, как в классической книге Четырёх) реализует двойную диспатчеризацию (ну и по аналогии можно реализовать произвольную диспатчеризацию). И там, где у языка с двойной диспатчеризацией будет очень простой код, этот самый Визитёр городит огромную кучу дополнительного кода.

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

По поводу ООП такого консенсуса нет, это я готов признать. Но своё мнение я высказал.

Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации. Также может быть полезен синтаксический сахар, для замены наследования реализаций композицией. Вот это подмножество действительно полезно и часто применимо. А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее. Вреда больше, чем пользы. И, что забавно, Go, Rust как раз и реализуют указанное подмножество.