Выскажу свое мнение по поводу перспектив Оберон-семейства.

1) "Маркетинговая сторона." Считаю бессмысленным противопоставлять Оберон, Оберон-2 и КП. Виртом 15 лет назад был дан толчок новому направлению, и то, что от него пошли ветки, доказывает лишь его успешность. Естественно, все продумать и предвидеть тогда было невозможным. Кое-что пришлось и придется менять. Будут развиваться версии. Сразу подчеркну: нужно не допустить их принципиального расхождения между собой. Но обеспечить 100%-совместимость тоже не удастся. Все наработки не могут развиваться единственной веточкой. Они должны составить скорее плотную гроздь, но не разрастаться до огромного дерева.

Ничего страшного в появлении версий нет. Это признак того, что Оберон-сектор живет и развивается. Что сейчас самое главное в Оберон-технологиях?
а) Стиль мышления. Нюансы синтаксиса и реализации не столь важны, главное, чтобы в российской индустрии и образовании прижился сам принцип построения модульного, расширяемого, надежного, простого ПО.
б) Это - реальная альтернатива ПО от Microsoft, и именно благодаря КП и ББ. Медленное умирание Borland оставляет всю армию Паскаль-программистов (и преподавателей) без реальной базы для своей работы. Эстафету сегодня может принять лишь ББ. Развитие Оберона как абсолютно независимого от конъюнктуры языка - заманчивая, но во многом утопичная идея. А сколько это займет времени? Год, два, три? А текущие задачи не ждут. И их решать надо сегодня: писать ПО, учить студентов, школьников... Для школы вообще выбор сейчас прост: не BB, так VB. Если победит последний, то года через три Оберон уже будет никому не нужен. И спор "Паскаль или С" станет бессмысленным. Ибо не будет ни того, ни другого. ИТ-отрасль страны окончательно превратится в мастерскую по подгонке "труб разного диаметра" от Microsoft, Oracle, SAP и иже с ними. А что можно предложить взамен, например, для деловых приложений и производственных систем? ETH Oberon? Имея в руках ББ, можно потеснить тот же 1С и VB. А если не потесним сейчас, то - при таких темпах автоматизации экономики и управления - уже не потесним вообще.
Поэтому давайте не будем выдумать проблем и противостояний там, где их нет. Пусть каждый решает текущие задачи, которые перед ним стоят. Если проект Оберона как "нейтральной полосы" обретет свое воплощение, проблемы стыковки с ним не возникнет. Переход пройдет легко и естественно. Т.к. самое главное - не нюансы синтаксиса и не кодировки исоходников, а стиль мышления. Стиль мышления сегоднящих и будущих российских ИТ-инженеров. Оберон, КП, ББ - в конце концов, все это только инструменты, на которых можно этот стиль отточить и применить в деле.

> -- Руслан Богатырев писал(а):
> Вот его и надо называть автоматом Калашникова (а не КП).

И автоматы Калашникова, между прочим, бывают разные. Тот, который был создан в 1947 году, тоже "стабильный, доказал свою жизнеспособность, нейтральный". И это ничуть не помешало появиться АК-74 (с новым калибром) и множеству модификаций. Потому, что иногда требуется и складной приклад, и подствольный гранатомет, и оптический прицел. И что это меняет? Главное, чтобы стрелял так же надежно, был совместим по главным деталям и мог выпускаться на одном конвейере.

2) "Техническая сторона." По поводу раширения Оберона в Обероне-2 и Компонентном Паскале.

а) Базовые типы. Вирт зафиксировал их размер в языке 15 лет назад в расчете на то, что еще много лет они будут оставаться актуальными. Так оно и случилось, 15 лет - большой срок. А что сейчас? Сейчас у нас не то что на подходе, а уже на пороге - 64-разрядные архитектуры. И цепляться за старый 32-разрядный стандарт смешно. Так или иначе, в самое ближайшее время придется переносить Оберон-системы на 64-разрядные платформы, а значит - принимать соответствующий INTEGER, LONGINT, REAL и иже с ними. И это действительно "не самое страшное" - это абсолютно нормальное, штатаное событие.

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

в) Использованию процедурных типов для формирования методов ничто не препятствует.
Однако на практике такая гибкость нужна не столь часто, а вот связанных методов в повседневной работе очень не хватает. Дело в том, что абсолютная расширяемость в любом случае недостижима. Когда над системой работает двое человек в своей лаборатории - это одно дело, а когда делается массовый продукт - совершенно другое. Конечному пользователю не только невозможно, но и не нужно позволять стыковать "все со всем" - это уже не модульность, а винегрет получается. В конечном счете, глобальным расширением будут заниматься сами разработчики и те, кто будет ими допущен к работе над проектом.
Именно поэтому явный модификатор EXTENSIBLE - вполне разумная вещь, так как разработчик лучше кого бы то ни было знает, что можно расширять, а что нельзя. Абсолютно безопасно в реальных проектах можно расширять лишь абстрактные типы, т.к. у них определен только интерфейс, а не поведение. Заменять произвольный метод произвольного объекта ой как опасно - его "соседи по типу" ждут определенных, не видимых снаружи, но отлично видимых внутри модуля, побочных эффектов. Ориентация на расширение "по умолчанию" - это аналог слабой типизации, когда предполагается, что программист, занимающийся расширением, предусмотрит все нюансы и последствия своих действий.
Расширяющее программирование в большинстве случаев должно оперировать как единицей расширения не методом, а типом и объектом. В ББ расширяемость обеспечивается концепцией "директорий". Существует абстрактный модуль, который содержит, кроме самих типов, еще и переменную-фабрику, которая создает конкретные реализации этих типов. При этом фабрика устанавливается ("инсталлируется") извне, без всякой перекомпиляции (так же, как и инициализация методов в варианте с процедурными полями). Например, по умолчанию свою реализацию для Ports предоставляет HostPorts, но можно создать свою и подключить ее прямо во время выполнения среды. Получаем не намного меньшую гибкость, чем в случае процедурных полей, однако при этом большую ясность и надежность.
Однако никто не мешает при необходимости использовать в КП стиль Оберон-1. Есть много задач, для которых он будет самым удобным.

г) Модификаторы ABSTRACT, EXTENSIBLE, LIMITED, EMPTY, NEW - это не навороты, а насущная необходмиость, если мы хотим иметь возможность выражать проектные решения в терминах языка. КП можно использовать как язык проектирования. Оберон-1 - нет. В противном случае множество ключевых моментов проекта придется отражать в текстовой документации или в "костылях"-диаграмах UML.