OberonCore

Как известно, языки, в которых объектно-ориентированность основана на классах (для
этого варианта OO будем использовать аббревиатуру CLOP – Class-Oriented Programming
[10]), критикуются (в том числе) за отсутствие гибкости и за проблемы разработки
повторно используемых компонент [11,12,13,14,15,16]. Приведем известную цитату Джо
Армстронга (Joe Armstrong), автора языка Erlang:

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

Понимая это, мы можем сделать первый шаг к определению OOP в новом языке – это
отказ от CLOP и от наследования реализаций.
Второй шаг следует из понимания того, что возможность повторного использования
компонентов (compile once, use everywhere) для разных устройств существенно
увеличивает эффективность COP. Частным следствием этого понимания, является
требование расширения объектов (добавления методов) без необходимости внесения
изменений в исходный код и с минимизацией перекомпиляции.

... а объективно как "утопить в Байкале".

Принципиальной чертой нового языка мы видим средства компонентно-
ориентированного программирования (COP – Component-Oriented Programming) [1], под
которым мы понимаем возможность сборки (существенной части) программы из готовых
компонент. Одним из шагов в направлении COP является, с нашей точки зрения,
правильный выбор средств OOP.
2. Подход к OOP
В текущей работе мы не рассматриваем COP напрямую, сосредоточившись на OO
парадигме. Заметим, что в настоящее время, ситуация с ОО парадигмой весьма
запутанная. По сути, в IT сообществе отсутствует общее понимание того, что такое OOP.
Достаточно отметить, что OOP в языках Go [2, 3] и Rust [4,5] принципиально отличается
от OOP в языках С++ и Java. Если добавить к списку языков Lua [6,7] и EO (Elegant
Objects) [8,9], мы увидим, что словом OOP называются существенно разные и часто
противоположные подходы. Для иллюстрации приведем сравнительную таблицу
конструкций языков (табл. 1):

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

Разработка операционных систем и средств разработки нового поколения для массовых пользовательских устройств
Корневые алгоритмы и компоненты операционных систем, разработка компиляторов (C/C++/Java/Kotlin/новый язык(!)), вирутальных машин, JIT-оптимизаций, продвинутых профилировщиков и отладчиков, технологий оптимизации на стыке аппаратуры и софта, систем верификации.

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

"топить ..." не опровергнуто.

"Почему провалилось ООП?"

Автор статьи Алексей Недоря, наверное, знаком кому-то из сообщества.

так он же не один:

https://beobaxter.livejournal.com/1184360.html

Автор статьи Алексей Недоря, наверное, знаком кому-то из сообщества.

Ну, про XDS все слышали. А некоторые ещё Mithril помнят.

В Орле познакомились и слушали его доклад.

так он же не один:

https://beobaxter.livejournal.com/1184360.html

> в "борьбе со сложностью программистского бытия"
Реально со сложностью положение такое же как в анекдоте:
- Давно вы страдаете эротическими галлюцинациями ?
- что вы, доктор, я не страдаю, я имим наслаждаюсь !

Я думаю это малореально. У них немного другая цель. Как я понял их цель - это сделать программирование приятным и веселым.

Вот всех и топить.

Ничего не понял. Можно чуть подробнее почему?

Почему топить? Ещё подробнее?