OberonCore

Судя по документу, одинарных слов уже явно не хватает

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

IMHO, соглашусь - по части методологии формализации. Так, у него всё так же непонятно отношение "программ" к "системам" - уже говорил. И сам по себе подход к отражению реальности как информоделей (исполнимый прогтекст + контрактные спецификации) м.б. и неплох - но объектный взгляд вызывает вопросы...
В то же время есть и вроде удачные вещи - как изложение основ логики.
Да и то, что говорится об инвариантах исполнения - разве не имеет смысл?..

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

Думаю следующий пример близкий программистам будет кстати. Одну и ту же предметную область - "программы для компьютера" - видят по разному:
1) интегрированная среда разработки;
2) JIT компилятор;
3) среда времени исполнения.
Едва ли стоит стремится к тому, чтобы у (1), (2) и (3) была одна общая библиотека с единственным описанием модели программных объектов. Пожалуй лучше написать три таких библиотеки - три описания одного и того же, но с разными акцентами на требуемые особые свойства рассматриваемых объектов.

Вполне возможно. Только важно, чтобы все библиотеки имели один источник/получались из одного источника. Под источником понимается целостное концептуальное представление.

Схемы обсуждались здесь: Заголовок: Оберон и проектирование систем
Инструменты обсуждали здесь: Заголовок: Рефакторинг: есть ли ему место в разработке систем?
О системах говорилось здесь: Заголовок: Языки системы и система языков

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

* Можно ли понимать так, что эта система должна включать три класса языков - по одному для нижнего, промежуточного и верхнего уровня? условно говоря - ПРОЛОГ, ЛИСП, Оберон/КП ?

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

* Как должна обобщаться эта архитектура на число уровней, большее 3-х? увеличением числа промежуточных уровней?

Языков может быть больше трёх. Например, специализированные языки, типа SQL или языки/протоколы сетевого взаимодействия/общения... Но если говорить предметно, то есть три базовых класса языков: язык действия (императивные и функциональные языки), язык мысли (логика и...) и язык чувства (искусство). По мере роста систем, программных в том числе, мы постепенно переходим ко второй группе языков. Большие системы (3+) стоят дорого и способствуют решению жизненно важных задач, поэтому содержат не только действующие элементы, но и элементы самоконтроля (контроль собственного состояния) и контроля состояния внешней/окружающей среды. Здесь без логики не обойтись. Если на начальном этапе развития достаточно просто знать своё состояние и состояние внешней среды, то потом потребуется контролировать динамику изменения состояний, соответствие (внутреннего и внешнего), частоту смены состояний (внутри и вовне), скорость переходных процессов, установление причин и следствий изменений и т.д. и т.п. Другими словами, системы должны будут научиться чувствовать, а затем и пред-чувствовать. И для передачи чувственных образов потребуются развитые языки, точно также, как языки нужны для передачи мыслей и действий. Если кто-то думает, что разные сферы искусства появились "сами собой"... "случайно", то отнюдь... И науки появились совершенно закономерно, как и полезная (индивидуальная и совместная) деятельность людей. Но это так... повод к размышлению.
Для современных систем (3+) достаточно двух базовых языковых классов (деятельность + зачатки логики).
Каждый уровень системы независим от других уровней в плане своего создания и развития. Можно провести аналогию... Есть чипмейкеры (создатели элементной базы), а есть те, кто пишет операционные системы (ОС) для работы с "железом". Но очередная версия операционной системы следует за пожеланиями пользователей, а не за новыми чипами. Совместимость чипов с новой ОС определяется протоколами/интерфейсами, на основе которых создаются драйвера. Пока уровень развития недостаточно высок, что приводит к различным коллизиям при взаимодействии устройств и ОС. Но по мере развития, вопросами согласования будут заниматься отдельные органы стандартизации, которые принимают и утверждают протоколы взаимодействия, и контролируют их исполнение. Чипмейкеры успешно продвигают эту модель, в отличие от производителей ОС. Но подвижки есть.
Независимость уровней систем, открытость/доступность описаний интерфейсов - это залог успешного (быстрого, экономичного - эффективного) развития систем. И, наоборот, закрытость интерфейсов, связность уровней - это залог их краха. В свою очередь, независимость уровней + открытость интерфейсов открывает перед разработчиками перспективу в свободе выбора средств реализации любого уровня (эффективность разработки и реализации при установленных/заданных параметрах качества). Моноязычные системы - это нонсенс... в перспективе.
Промежуточные уровни не должны появляться, это ломает архитектуру системы (возможно, речь идёт о подуровнях). Подуровни не имеют своего интерфейса, они должны соответствовать интерфейсу своего уровня. Введение подуровней - это нормальный процесс внутреннего развития уровня. А рост самой системы может быть только вверх (и иногда в процессе проектирования - вниз, за счёт дополнительной декомпозиции). В свою очередь, рост вверх, означает появление новых целей и задач, т.е. вычленения из внешней среды новых функций и... ресурсов.

Модель системы одна, но она включает модели уровней...
Интерфейс - это протокол/декларация. Эту декларацию можно использовать из разных языков. Например, из программы написанной на Pascal или Oberon можно взаимодействовать с подпрограммами ОС, написанной на С++, если соблюдаются протоколы обращения к подпрограммам ОС.
Любая предметная область (даже выдуманная) - часть мироздания, а мироздание - это система...

Оно-то да, но разрабатываться отдельно друг от друга могут уровни, их реализации, а не модели. Модели уровней ограничены моделью всей системы (хотя бы частично). Нет?
Я просто хотел обобщить как понятие языка программирования как он есть сейчас, так и интерфейсов. Разве интерфейс в виде подпрограмм на Pascal и C, на которых написан уровень, не представляют собой язык общения с данным уровнем? Как бы было удобнее, если бы общение с уровнем представляло собой не последовательности вызовов подпрограмм (порядок имеет значение!), а удобный синтаксис... Например, представим синтаксис SQL для конкретных целей конкретного уровня.
А здесь я что-то не могу связать сообщения. У меня что-то неправильно?

Нет - это слишком категорично. Один и тот же уровень может работать с разными системами/принадлежать разным системам/разделяться между системами. Это отчасти объясняет самостоятельность уровней, в том числе и их самостоятельное/независимое моделирование. Мы привыкли к тому, что система создаётся в одном месте и централизовано, но так будет не всегда. Чем дальше будет развиваться проектное производство (производство ПО, в том числе), тем чётче будет специализация/разделение труда. Это приведёт к тому, что каждый уровень (и даже подуровень) системы будет создаваться отдельными коллективами.
SQL - это хороший пример декларативного языка, языка описания сущностей и связей между ними. Но он не пригоден для описания действий. Для этого вводят специальные конструкции на некотором диалекте, для написания триггеров, хранимых процедур, исполнительских блоков и пр. Но речь не об этом... Мне бы хотелось отметить, что архитектура системы, структура уровней и интерфейсов - это самостоятельная задача для проектировщиков, она не должна быть связана с выбором языков разработки. Наоборот, язык разработки должен соответствовать своему месту (уровню, задаче). При этом нельзя сбрасывать со счетов плеяду языков, предназначенных для решения узкого круга специализированных задач. Для проектировщиков и разработчиков язык - это инструмент. И попытки унификации "всеобщего языка" порой очень напоминают попытки скрестить лопату с хирургическим скальпелем...
Специалистам, которые работают с системой, нужны и декларативные языки, и императивные языки, и языки исчисления предикатов... просто в силу разности задач... решаемых в рамках системы.
Означает ли сказанное, что нет и не может быть "общего языка"?.. Нет, не означает. Понятие языковой общности не основано на каких-то общих конструкциях полезных на любом уровне, при решении любых задач... Этого нет и быть не может. Общность возможна только на основе семантики... на основе понимания того, что "малое в большом, а большое в малом". Хорошим примером мог бы служить древнерусский язык, где смыслом (ключевым/основополагающим/отражающим мироздание) наделялась каждая буква алфавита! Из осмысленных букв складывались частные осмысленные слова, из слов - предложения. Древние понимали, что утрата смысла хотя бы в одном месте, на одном из этапов, делает бессмысленными любые построения. Для нас буквы - это просто звук... увы...

Ну и теперь вопрос деловой к alexus - в русле темы. Уровни языков соответствуют уровням систем? Или выделяются иначе - как?

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

Вот попробовать бы и определить облик класса языков для каждого уровня... хотя бы в виде "лексика-правила"...

Вроде бы об этом мы говорили... Для формирования языка надо знать:

1. Архитектуру системы (количество уровней, их существо и интерфейсы);
2. Сущности уровня, включая их атрибуты, свойства, действия;
3. Связи между сущностями, включая передаваемые по связям ресурсы.

Мы с Вами рассматривали, в качестве примера, структуру подсистем сбыта и снабжения предприятия, как системы. Выделяли ключевые сущности и связи... Это и есть основа языка, по моему мнению. Примерно на таком же уровне рассматривались эти вопросы (формирования языков) при обсуждении проекта СУБД.

А Вы видите какие-то инвариантные к "предметке" и зависящие только от уровня требования к определению языка/семейства этого уровня?

Владислав, я пока занят... но вопрос интересный, чуть позже я на него постараюсь ответить.

Вероятно, я тоже пока буду занят (а то много активности было в сети ), но позже обязательно постараюсь ознакомиться с Вашими ответами. Удачи!