"...for the times they are a-changing..." 😔

бота напишут

Так и динамическая дипизация тут ни при чём. В приведённых примерах проблему вызывает изменяемость и передача параметров по ссылке.

Что мешает то же самое делать с произвольным языком X? Напомню, кстати, realtime-приложения - это не те, которые вот прям за наносекунду всё обсчитывают, а те, для которых гарантированы временные ограничения на работу участков кода. Если у программиста не кривые руки, то можно и на Java такое писать, если кривые, то и на Си он ничего не напишет. Множество раз видел, как люди устраивали инверсии приоритетов, как алгоритмы писали кривые и т.д. и т.п. и считали при этом, что Си/Си++ им автоматически даст какой-то realtime.

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

любопытно посмотреть на подобный код

А зачем это для управления АЭС? В ответственных задачах, обычно, всё делают inhouse и специально под конкретный проект. Если БД какие-то и есть или интеграция с какими-то библиотеками, то очень и очень далеко от ядра системы. Поэтому, можно и Oberon взять. Не самый плохой выбор, действительно.

А мне больше стиль Theo de Raadt нравился. И да, он тоже уже не торт.

Так любые более или менее практичные примеры на Idris.

Для рил-тайма и прочих вычислительных задач же, наверное, нужны не действительные числа, а формализация машинных IEEE float'ов? В каком-нибудь CompCert должно быть? Но я не смотрел какой там ужас с машинными числами. 😊

А чего тогда не Lisp? В котором сколько ключевых слов? По-моему, четыре всего: lambda, rec и cond (:

Да нет, в Лисп, помнится, побольше нужно, car и cdr как минимум ещё. По этому критерию Smalltalk как раз почти всех уделает. Ну или Forth. 😊

Ссылки там не при чем в C#, JS и других managed ЯП тоже везде ссылки генераторы / итераторы есть, но такого не будет. В Python генераторы просто ленивые и выполняются только тогда когда все это преврашается явно в список.

Можно кодировкой воспользоваться и в lambd-ы всё упихать. Я просто к тому, что критерий по ключевым словам странный, как минимум.

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

Тут даже ленивость не особо при чём — в самом ленивом Haskell такого тоже не будет. 😊
Проблема, по-видимому, в небрежной реализации call-by-name и использовании динамического скоупа вместо лексического.

Это-то и так понятно. 😊

Кстати, а есть какая-нибудь вменяемая мера (сложности) для семантики ЯП?

Во-первых, "коболизация" может "внезапно" случиться почти с любым языком — именно поэтому хорошо брать простой язык, которому можно сравнительно быстро обучить.
Во-вторых, не хотелось бы, чтобы экономили на программистах и прочих специалистах для АЭС. 😊

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