Вот поспела и ключевая фраза, поясняющая мотивацию многоуважаемого оппонента: нас в который раз пытаются убедить в том, что данный 3GL «самый что ни на есть»...

Что характерно, этот тезис (да и вся дискуссия) последовал после формулировки идеи более четкого позиционирования языков Оберон-семейства.
См. »сообщение 3790« и »сообщение 3795«
Ключевым направлением для Оберонов является контроль сложности. Чем-чем, а этим мэйнстрим похвастать не может. Возможно, выскажу крамольную мысль, но Обероны нужны (по-настоящему) весьма узкому кругу людей. Это элитарная вещь. При этом она может быть востребована и массами, но в упрощенческой форме -- усовершенствованного Паскаля. Так что две крайности -- либо совсем неподготовленные (но не изуродованные Бейсиком и Си) люди, либо специалисты в сфере таких задач, где надежность и контроль сложности стоят по важности на первом месте.

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

Мне представляется, что из подобных кавалерийских наскоков (уже не первый на моей памяти) стоит извлекать уроки на будущее. Чем крепче на ноги будет становиться Оберон-сообщество и Оберон-инфраструктура, тем эти нападки, на мой взгляд, будут только усиливаться...

Ответ на »сообщение 3992« (ASU)
___________________________
>>> Любая система имеет иерархическое строение

Только, настаиваю, самая примитивная.
В иерархической системе минимум связей.
Контрпример:
А зависит от В, В зависит от С, С зависит от А.
Где иерархия?
Только система с циклическими связями "не равна сумме частей".
Потому и интересна, продуктивна.
А деревянная топология - это примитив, хоть и ужасно распространённый.
"Программирование заставило дерево зацвести".

>>> интерфейсы обязаны быть устойчивыми

Только для статики - это простейшее описание системы типа классификация.
Для динамических систем в момент изменения межмодульные связи обязаны меняться.
Отсюда и интерфейсы сначала, а потом модули - структура-то закостенела!
Строим раз и навсегда каркас из интерфейсов, а на него вешаем "элементы".

На этих двух зыбучих песках зиждется всё здание.
Отсюда интерфейсы имеют самодовлеющую сущность.
Отсюда и методика изложения ... (спокойно, Ипполит, спокойно...)
... скажем ... затуманивания ошибок, которые очевидны при ясном изложении.

А претензия на всеобщий системообразующий взгляд!
Но, увы, механицизм и статика. Конец XIX - начало XX века. На уровне Берталанфи.
Множественность описания систем, отказ от иерархии, открытые системы,
системы переменной структуры, теория нелинейных систем - всё прошло мимо
взгляда философа.

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

P.S. Прошу прощения у уважаемого сообщества за излишнюю эмоциональность,
но так достали продавцы энергии из вакуума и из рукава! Простая панацея forever!
Опять на полном серьёзе обсуждали возможность получить из 1 кВт элэнергии 2 кВт тепла.
И зачем оптимизация и скурпулёзное исследование! И всё та же живучая фирма.
И манера изложения так что-то напоминает ...

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

Один и тот же язык программирования может использоваться как язык макетирования, язык моделирования, язык спецификаций, язык проектирования, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки, но это не означает, что такой подход разумен и полезен в отношении конкретных условий (предметной области, предпочтений и квалификации исполнителей, условий проекта и т.п.).

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

Сопоставление языка программирования Оберон с методологиями некорректно. Это вещи разного калибра. Сопоставление с другими языками программирования должно быть обусловлено контекстом такого сопоставления (фиксация методологии/спектра задач, выбор эталонного языка реализации, сопоставление с ним Оберона).

Эти тезисы инвариантны относительно Оберона. В упомянутом тексте можно сделать замену слова "Оберон" на название любого другого языка программирования. Смысл останется прежним.

Ответ на »сообщение 4041« (Сергей Тарасов)
___________________________

>> Полиморфизм крайне полезная концепция, чтобы понять это надо рассмотреть подуровни системы. Наверное, разговор о системах надо выносить из ветки об Обероне...
> Будет время - заходите к нам на арбинаду, например сюда.
Хм... Неужели спокойная жизнь надоела?.. :)
Хорошо, завтра зайду.

Ответ на »сообщение 4026« (Сергей Перовский)
___________________________
>> Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.
> Давайте, все таки вести дискуссию на русском языке, как прописано в правилах сайта :)
В русском языке термин "системное программирование" произошел не от филосовского или научного понятия "система", а от конкретного (и не очень удачного) термина "операционная система". Так уж получилось.
Понимаете, Сергей, если я откажусь от своего понимания «системности» в пользу «общепринятого», то... проиграю от этого не я, а те, кто защищает (от кого?) Оберон. Здесь уже неоднократно говорилось, о том, что Оберон особенно эффективен для разработки программных... э-э-э-э ... комплексов, а не маленьких программ. И эффективен потому, что... он имеет гибкие механизмы, строгие ограничения и требования, в том числе, по импорту. Но как видно из бурного обсуждения... ограничения непродуманны, а требования порой избыточны. Попробуйте попросить объяснить, что же такое квалифицированный интерфейс?.. Так на какие же области программирования ориентирован Оберон?.. Я хорошо понимаю, что сейчас в мой адрес снова полетят «тухлые помидоры», но можно быть уверенным, что вразумительный ответ вряд ли последует.
Что лично меня напрягает?.. Есть серьезная проблема создания средств адекватных решаемым задачам. Но вместо того, чтобы хотя бы сформулировать эти задачи, попробовать предложить решения... нас в который раз пытаются убедить в том, что данный 3GL «самый что ни на есть»...
В свое время Вирт, Дейкстра, Хоар, Кнут и многие другие проделали огромную работу по разработке и популяризации методов структурного программирования. Честь и хвала им за это! Сегодня все тот же кризис «сложности», который делает необходимым смену парадигм, а вместо этого постоянно говорят об очередных «висюльках» и «бантиках»... И при этом требуют(!): сравни мои «висюльки» с другими... А если не похвалишь, то обижаются... прямо по-взрослому...

Ответ на »сообщение 4016« (ASU)
___________________________

Полиморфизм крайне полезная концепция, чтобы понять это надо рассмотреть подуровни системы. Наверное, разговор о системах надо выносить из ветки об Обероне...
Будет время - заходите к нам на арбинаду, например сюда.
http://www.arbinada.com/modules.php?name=Forums&file=viewforum&f=35
Здесь как-то нервно и бурно обсуждение проходит.

Ответ на »сообщение 4038« (Сергей Перовский)
___________________________

Естественное желание, написать новый модуль С, который будет реализовывать оба интерфейса.

Если изучение (сопоставление), длящееся не 1 сек., показывает идентичность, какие проблемы дать "подмене" имя, соответствующее интерфейсу? В Оберон-модуле для этого надо внести правки в двух местах -- в "открывающей скобке" модуля (MODULE A;) и в его "закрывающей скобке" (END A.)

Ответ на »сообщение 4031« (Илья Ермаков)
___________________________
>>>Елки-палки... Сколько работаю - не знал про эту штуку.
А Вы GTK -версию не смотрели? Там они используются.
>>>Давайте перейдем на наш форум, чтобы не захламлять ветку
Иду.

Ответ на »сообщение 4037« (Илья Ермаков)
___________________________
>>>Но в очень многих случаях предполагается инвариант, что интерфейс с одним именем будет подключен для всех модулей приложения к одной, общей реализации.
Я и не предлагаю загружать множество реализаций одновременно, "таблица синонимов" системная штука, а не принадлежность модуля.
Но представьте следующую ситуацию: в системе описаны и реализованы интерфейсы A и B, изучение их реализации показывает практически полную идентичность, например с точностью до параметра - очень частая история. Естественное желание, написать новый модуль С, который будет реализовывать оба интерфейса. Ан нет, будте добры внести исправления во все модули использующие А и В. При всей ущербности СОМ интерфейса, он это сделать позволяет.

Ответ на »сообщение 4034« (Сергей Перовский)
___________________________

Ответ на »сообщение 4027« (Руслан Богатырев)
___________________________
А как же насчет "без перетрансляции"?
Вынесение таблицы синонимов (по сути таблицы интерфейс - модуль реализации) из модуля в отдельную сущность заметно увеличило бы гибкость межмодульных отношений.

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

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