Ответ на »сообщение 4355« (Руслан Богатырев)
___________________________
>>> Здесь нужно чувство меры: представители всех указанных выше профессий конечно могут общаться каждый на своем "птичьем" языке, но будет ли от этого толк? Нужно искать золотую середину -- минимизировать число языков (абстрактных слоев), понимая, что есть ключевая тройка "замысел --> проект --> строительство".
>>> Но при этом не стоит заниматься проработкой архитектуры, коммуникаций, проектных решений исключительно на языке программирования (который для этого не предназначен). Поверьте, этим занимались и занимаются не от хорошей жизни. Не надо язык программирования всячески расширять и дополнять в эту сторону -- у него свои функции -- регламентированная модель непосредственной работы с компьютером.
Вообще, будет хорошо, если они начнут нормально общаться между собой хотя бы на русском. Потому, что на нем можно объяснить все что угодно, что вообще можно объяснить.
У естественных языков грамматика, подчас проще, чем у формальных языков программирования, а семантическая емкость просто зашкаливает… А все потому, что семантика формальных языков вынесена на уровень грамматики, чтобы обеспечить однозначность передачи (так как CPU еще не научился мыслить).  Хотите обеспечить для них семантическую емкость сравнимую с естественными языками, не потеряв в однозначности – будьте добры построить грамматику соответствующего размера.
Вот языки и плодятся как кролики. Конечно, необходимо искать баланс между количеством классов решаемых задач и размером языков, на которых каждый класс задач описывается.

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

Правда, мы, похоже, немного не поняли друг друга… Я-то говорил, что не надо делить языки на те, с помощью которых разрабатываются модули и те, с помощью которых они объединяются в единое целое. Так как в объединяющий язык все равно придется внести большую часть понятийного аппарата.
Вот когда вы уже написали 100 exe-шников, запустили их на 1000 компьютеров по всему миру, объединили их в сеть и назвали это Системой. Вот тогда, управлять такой системой и конфигурировать такую систему на Обероне, а также C++ и Delphi /Pascal вряд ли стоит.  Потому, что эта система иного уровня с совершенно иным набором абстракций.

>>> Среда -- это "судебная практика", причем ... как у нас

Спасибо. Смешное сравнение :)

Модули, которые не взаимодействуют в модульном языке - тоже.

>>> Да, можно и "Построение программных систем".
Да нет, это же только уровень 6 классификации Богатырёва.
Лучше так:
"Построение архитектуры систем из модулей без связей".
или точнее
"Помечтаем о застывшей музыке систем по Берталанфи".

Ответ на »сообщение 4362« (Руслан Богатырев)
___________________________

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

Язык -- это "законодательная база". Любое его изменение -- это изменение законодательства, правил игры, необходимость пересмотра налаженных схем и решений, зависящих от "законодательной базы".

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

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

Ответ на »сообщение 4360« (Руслан Богатырев)
___________________________
>>> Почему обязательно распределенных? Может быть, просто: "Построение программных систем" или "Конструирование программных систем"?
Да, можно и "Построение программных систем".
Но, на мой взгляд, термин "конструирование" лучше не использовать, так как его семнтика ближе к проектированию и подготовке... реализация и эксплуатация не менее важна.

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


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

Ну если для Вас на уровне Оберон-модуля проблем нет, то попробую их сформулировать:
1. Есть группа взаимосвязанных модулей (подсистема, назовите хоть как). Эта взаимосвязь должна контролироваться как на этапе проектирования, так и на этапе выполнения (элементарная задача: выгрузить динамически все модули данной подсистемы и подгрузить -- если надо -- замену).
2. Реализован Оберон-модуль с некоторым интерфейсом. Возникает необходимость в создании его клонов (назовем, скажем, параметризацией заготовки). Как будем решать? Copy-paste?
3. Интерфейсы (модули) неравноправны -- есть публичные, есть служебные; есть проверенные (trusted), есть сырые; есть верифицируемые, есть бесконтрольные...

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

Чтобы понять границы/возможности/проблемы языка, достаточно прочитать и проанализировать в кабинетной тиши его формальное описание. Для системы требуется экспериментальный опыт: что и происходит на практике -- выпускается очередная версия системы программирования (IDE) и 1-2 месяца уходит на выявление ее особенностей (а будет ли она поддерживать тот парк наших программ и средств, что уже наработан, не возникает ли там новых проблем). А через полгодика -- новый релиз. И так непрерывно. Собственно, идея смещения акцента с языка в сторону среды -- это элементарная основа современной бизнес-модели выкачивания денег из населения. Чтобы выкачивать деньги, язык должен меняться (новые версии, новые стандарты), среда постоянно обновляться (иначе, при тиражируемом ПО и уровне пиратства -- кранты производителю) -- а вы, господа-программисты, тестируйте на собственном бизнесе очередную версию и восхищайтесь (или плюйтесь -- кому как карта ляжет)!

По поводу языка для создания систем.

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

Программу, по хорошему, надо будет хранить в отдельном файле. Если это система Оберон или ББ, то этот файл будет начинатся со слова MODULE ...

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

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

Ответ на »сообщение 4357« (Стэн)
___________________________

Назовем её, например – «Построение распределенных систем».
Почему обязательно распределенных? Может быть, просто: "Построение программных систем" или "Конструирование программных систем"?

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

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

>>>Руслан Богатырев, IMHO, правильно отметил отсутствие в Обероне более крупной конструкции, чем модуль, назвав ее "кластером"
А перед этим он же отметил, что во вложенных модулях нет небходимости. ;-)

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

Ответ на »сообщение 4357« (Стэн)
___________________________
Не плохо было бы перенести туда сообщения начиная, например с № 4352, если движок форума позволяет?!

Обращение!
Господа, может нам все-таки стоит создать новую тему? А то многие, действительно интересные вопросы, которые здесь поднимаются, имеют к Оберону очень отдаленное отношение.
Назовем её, например – «Построение распределенных систем».
Уважаемые модераторы, как вы на это смотрите?