Что такое Оберон-парадигма?

Дам ответ в стиле "как лично я понимаю Оберон-парадигму и что она мне даёт".

Мой взгляд предыдущих лет я излагал в ряде статей:http://i.ermakov.pw/pubs.php(в частности. "Оберон-технологии: что это такое?" и "Некоторые идеи архитектуры Оберон-систем".

Попробую из текущего момента и основными мазками.

1. Что такое по своим качествам язык Оберон в ряду остальных?

Ф. В. Ткачёв когда-то показывал его место на плоскости из двух осей: быстродействие (=комплируемость) и гибкость (расширяемость).

Часть языков группируются вдоль первой оси, часть - вдоль второй (динамические языки) - и очень мало - в верхнем правом углу. Как пример проблемы - постоянная гибридизация пар языков, допустим, в игрострое или системных задачах, или "научке" - одного быстрого для ресурсоёмкой части (С++, например) и второго, удобного для скриптования и интерактивной работы (Python, Lua, Юникс-скрипты всяческие - тот Python, TCL/Tk, Shell). Оберон оказывается именно в этом углу. Спорный вопрос - кто там ещё и насколько сопоставим, но что таких немного - это понятно. Те же Java и C# сейчас обыгрывают Оберон по быстродействию только за счёт эффективных новых реализаций и отсутствия инвестиций в современные компиляторы Оберона. Обыгрывают с супер-сложными рантаймами, нивелирующими их языковые проблемы (типа только динамических структур и т.п.). Если же считать одной из составляющих гибкости-расширяемости не только рефлексию и динамическое связывание компонент - а ещё и общую простоту... Ведь что легче сопровождать и развивать, на протяжении двух-трёх десятков лет? И для написания сиюминутного "клея" что легче использовать (если человек берётся за программу раз в полгода - что ему легче вспомнить?)

Я бы выделил для выяснения места Оберона в ИТ-экосистеме другие 3 оси:

Простота - жёсткость - расширяемость.

Жёсткость - в смысле возможности создать статически проверяемый "каркас жёсткости" для программы. Как приятное следствие - возможность разрабатывать "почти готовое ПО" без обильного покрытия тестами каждого мелкого кубика.

Трудно найти много соседей Оберону в верхнем дальнем углу этих трёх осей.

Жёсткость - расширяемость: Ada, C#, Java, Haskell

Простота - жёсткость: ну, это скорее к языкам прошлого поколения (Modula-2, старый Pascal, нераздутый Fortran в некоторой мере, наверное...)

Простота-расширяемость: Лиспы всякие, Луа и прочие.

А всё вместе? Только что-то близкое, та же Modula-3. Может быть, нечто из компактного статически типизированного компилируемого функционального (OCaml какой-нибудь?).

Далее, недавно отвечал для себя на вопрос о различиях между той же Modula-3 и КП. Modula-3 нравится и на "оторванный от конкретики", чисто эстетический взгляд может смотреться более гармоничной. Однако что-то где-то лично меня напрягает. Как с теми же перечислимыми типами и проч.: вроде, для инженера и "эстетично, надёжно" и т.п. Но... Потом сформулировал своё ощущение: это уже попытка дать какие-то базовые вещи, полезные для предметных областей, для выражения семантики задачи. Но это скользкий путь - ибо задачи столь многообразны, что любые такие кубики быстро начинают жать (кому-то ещё и единицы измерения нужно контролировать - и чем больше зарываешься, тем более многообразия. Единицы измерения же контролировать можно уже с таким количеством нюансов, что не сделаешь заранее ничего, пригодного для широкого круга задач). Отсюда становимся на путь не определять в языке, а давать определять части языка динамически - и получаем взрыв безумия типа Nemerle и ко. Таким образом, имеет смысл вообще исключить из языка всё, сколь-нибудь ориентированное на прикладную специфику. А оставить языку 3 функции: 1) классно абстрагировать от физической машины, при этом оставляя полную прозрачность в отображении на императивный вычислитель; 2) давать "рёбра жёсткости" - средства статического контроля, позволяющие отсеять процентов 80 наиболее досаждающих ошибок, не гоняясь за каждой остальной мелочью, коих туча разных. Не нужно думать, что от контроля прикладной семантики мы отказываемся. Всегда есть возможность заложить уже свои рёбра жёсткости в фреймворках, чтобы уже защитить себя от каких-то нарушений прикладной семантики. 3) Давать средства расширения (полиморфизм и динамическое связывание), пригодных для безболезненного включения в систему компонентов, неизвестных на этапе её создания. Эти 3 функции в точности и оставлены в том же КП. При этом КП расширен над Обероном только по линии этих 3 функций, никаких "реверансов" в сторону прикладной семантики.