Ну как бы композиция. Только это должно быть что то более удобное чем агрегация или миксины

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

А еще, работы по формализации заставляют меня вспомнить, что когда-то programming was fun и авторы Sketchpad и Smalltalk, как и пользователи эти систем, программировали с удовольствием.
Хотелось бы пожелать всем архитекторам новых языков не лишать такого же удовольствия своих пользователей :)

Enterprise Development is not fun and newer will be.

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

Поэтому и языки становятся оптимизированы не под фан, а под надёжность, совместимость, observability и прочие скучные свойства.

В Go например можно делать композицию как структур так и интерфейсов

type HTTPClientСontext struct {
  HTTPGetterСontext
  HTTPSetterСontext
}

HTTPClient interface {
 HTTPGetter
 HTTPPoster
}
HTTPPoster interface {
  Post(…)
}

HTTPGetter interface {
  Get(…)
}

Там жи нету ооп!

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

Автоматизировать можно что то, что уже прошло проверку временем и боем и уже стабилизировалось/стандартизировалось, а тут вот каждый год очередной it-гигант свой ЯП изобретает

Верить хочется, но лично мне не можется. Автоматизация напрашивается, но её не видать и на горизонте. Глядя на зоопарк форматов и "соглашений" для одних только HTTP API сервисов - REST, который каждый интерпретирует по-своему, с HATEOAS и без, JSON-RPC, gRPC, GraphQL и "старые добрые" XML Web Services - мне не кажется, что вопрос интеграции автоматизируется в ближайшие 5 лет... 😞

55 лет

Я считаю, что имеется существенно ненулевая вероятность, что за следующие 10-20 лет реально бОльшую часть этой "нудной" (технической-интеграционной) программистской работы автоматизирует так называемый Искусственный Интеллект. Для этого даже AGI не нужен, который, я думаю, тоже появится в течение лет 30.

"Information technology has been praised as a labor saver
and cursed as a destroyer of obsolete jobs. But the entire
edifice of modern computing rests on a fundamental irony:
the software that makes it all possible is, in a very real
sense, handmade. Every miraculous thing computers can
accomplish begins with a human programmer entering lines
of code by hand, character by character."

Думаю вот заняться таки VR IDE, чтобы немного более пространственно это все писать, не character by character.

Ну, кстати, распространение Machine Learning based систем таки меняет это положение вещей... Насколько быстро и успешно - интересный вопрос.

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

TabNine довольно неплохо дополняет большие куски кода, КОГДА угадывает правильно.

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

Конечно, если приходится писать 25 вербозных стейтклассов - уже что-то явно не так.

Но про язык ВИР мы так ничего и не узнали...

да, по-моему, ту ссылку здесь разместил бот-ретранслятор ))