Oberon space

Вместо этого надо делать так, как это делается в наших уютненьких телекомах: пользоваться стандартными протоколами и реализовывать их. Телекомы то давным давно истинно компонентны, а не так как на десктопах, написал компонент, высунул соску со одним из стандартных протоколов и всё.

Я про то и говорю.

Если говорить о стандарте для предметно-ориентированного ПО, то как раз и нужно нечто ББ-шных составных документов и сторов.
Альтернативы не видно. ББ в качестве первого хорошего приближения подходит. Дальше можно разработать что-то менее продукто-завязанное. Но тут нужно раскрепостить мысль в плане простых, скромных решений - в этом ББ как раз должен помочь. Иначе ИТ-шниками будет опять такая хреновина нагромождена... как с XML, что пользоваться нормальному прикладнику будет ад кромешный.

Значит в Оберонах существенная проблема. В паскалях традиционно можно обращаться ко всем идентификаторам модуля точно так же, как и к идентификаторам других модулей. Чем это вас смущает?

В Борланд-Паскалях. В Аде - нет (насколько помню).

И это правильно, т.к. общий механизм "прорыва через перекрытие" сделать всё равно нельзя. Если у Вас процедура второго уровня, как Вы доберётесь до перекрытой переменной в объемлющей процедуре?

Кстати, что рекламировать то? :-) Инструменты никому не нужны, народу нужно решение каких-то их проблем. Итак, вопрос, какие проблемы решит оберон лучше тем то что имеется у людей сейчас? (да, и какой именно оберон?)

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

Варианты? Какой инструмент эффективно и безопасно можно дать в руки? Чтоб практично и в то же время надёжно, как "корсет"? Как могут писать предметники, если не ограничивать их фантазию, хорошо известно. Им ведь некогда, так и тянет какую-нибудь фичу использовать волшебную сиюминутную.

Вообще говоря да (перспектива менеджмента кучи мелких модулей раздражает, по крайней мере, в текущей реализации ББ), но для образовательных целей такой стиль самое то ...
в отличие от Хацкельного.

Зато этот мелкий модуль один раз реализован - и эксплуатируется, без изменений. Возникли вариации - делается другой, новый. Исходный код "твёрдый", "отлитый".

Нужен рост реального сектора вообще. А от него обычно идут реальные, серьёзные запросы.
У нас профессура с машиностроительных кафедр посматривает на программёрский "Институт информационных технологий"  весьма скептично, потому что те вообще не готовы решать их задачи (тот самый синдром "компьютерных гениев").
(Тут надо пояснить, что я сам не работаю в ИТ-шном подразделении, я как бы полностью сбоку, в Технологическом институте, с СПО-шниками, сам себе хозяин, и работаю как раз бок о бок с машиностроительными кафедрами; вижу эту ситуацию сбоку очень отчётливо).

Предметно-ориентированное ПО для реального сектора - вполне себе killer-ниша для Оберонов.

Если экспортируется только ABSTRACT-тип, то там всё сверху модуля.

В среде нажать Ctrl-D, чтобы увидеть спецификацию, не проблема. (А не раз говорилось, что Обероны без среды теряют очень многое).

По поводу первичности спецификации - я с Вами соглашусь, рассуждая эдак "вообще". Но в конкретно своей практике, по причине того же переноса акцента на ABTSRACT-типы и т.п., я имею подтверждение того, что спецификации на модули не востребованы. Они востребованы, безусловно, когда могло быть несколько реализаций одного модуля. Сейчас (в компонентном ООП) так не делается.

И это Вы называете простым ЯП и проталкиваете его  для начинающих ? - мля... да и только.

А Вы считаете что ООП имеет отношение к начинающим? (утрирую)
К начинающим имеет отношение использование объектов, это проходит на ура.

Как вводить понятия ООП - вопрос вообще открытый. У меня есть хорошая безболезненная последовательность, поддержанная примерами, но только в этом году она сложилась. Дело начинается с объявления типов, расширяющих некоторые стандартные (сначала расширение Services.Action, для создания асинхронных действий; потом расширение Views.View), такие типы вообще не экспортируются. Потом в какой-то момент, имея уже графический объект (игра "Сапёр"), отделяем от вьюшки модель - и вот тут-то впервые создаём свой тип. И ABSTRACT появляется тоже естественно (тем более, что до этого мы занимались тем, что такие ABSTRACT-ы расширяли-реализовывали). Проблем не замечено.

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

ООП ещё требует осмысления и доочищения, это понятно, но на данном уровне сбалансированнее, чем в КП, пока не видать.

Плодить иерархию по пустякам...

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

Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях. Объём работы не увеличивается, т.к. как раз дефинишн Оберон генерирует автоматом, только звёздочки успевай ставить... Это как раз и к вопросу о том, почему в Оберонах теряет актуальность явное объявление спецификаций. Основные спецификации фиксируются в объявлениях ABSTRACT-типов.