Ответ на »сообщение 4020« (ASU)
___________________________
>>>Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.
Давайте, все таки вести дискуссию на русском языке, как прописано в правилах сайта :)
В русском языке термин "системное программирование" произошел не от филосовского или научного понятия "система", а от конкретного (и не очень удачного) термина "операционная система". Так уж получилось.
Я, например, хотел бы использовать термин "авторемонтник" для обозначения самовосстанавливающегося механизма. Но термин уже занят мужиком, ремонтирующим самобеглые повозки :(

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

Ответ на »сообщение 3997« (MS)
___________________________
ООП vs Модульное программирование?
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...
Насколько принципиально наличие в этом ряду библиотек и объектов? И именно в этих местах?

Ответ на »сообщение 4019« (Руслан Богатырев)
___________________________
>>>Тезис о квалифицирующем импорте был просто предлогом поговорить на тему системности в ветке по Оберонам.
Не надо так резко. Проблема на самом деле существует.
Оберон предполагает автоматическую сборку описания интерфейса по ГОТОВОЙ РЕАЛИЗАЦИИ - только звездочки поставить.
Тогда как описание интерфейса должно предшествовать разработке модуля.
Когда мы создаем аппаратуру с заданным интерфейсом, предполагается, что проведена работа по разработке интерфейса, он описан в некоторых документах до того, как начинается разработка конкретного железа.
Вы именуете эти стандарты протоколами, но термин интерфейс гораздо точнее отражает их смысл.
Посмотрите, например, спецификацию IDE. Там все, от протоколов до физических размеров. Полное описание интерфейса.

>>>Имеет смысл также понимать, что интерфейсы (межуровневые, межэлементные) той или иной реализуемой системы не обязаны отображаться один в один на интерфейсы Оберон-модулей, которые во избежание терминологической путаницы предлагаю называть спецификациями модулей (DEFINITION).
Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.

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

Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.

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

Мной ранее утверждалось, что язык Оберон является языком системного программирования (systems programming) в понимании терминологии, принятой в области программирования (если будем придерживаться строгости и конкретики, то американской классификационной системы системы ACM -- computer science и software engineering).

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

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

Ответ на »сообщение 4017« (Илья Ермаков)
___________________________
Правильно. Теперь Вы согласны, что интерфейс первичен, а модули вторичны и даже третичны?.. Тогда о каком выделении экспорта и импорта в рабочих модулях Оберон здесь так долго шел разговор?.
Об экспорте и импорте интерфейсов.
И о том, что любой использованный внешний интерфейс нужно явно предварять его именем в каждом месте его использования в коде.

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

Ответ на »сообщение 4017« (Илья Ермаков)
___________________________
На всякий случай повторю, что Оберон для создания систем ничуть не лучше других языков, он развивает идеи Н. Вирта, но к системномк программированию не приблизился ни на йоту. Я не ругаю Оберон, как не ругаю и другие языки, но называть его системным – нонсенс.

Уж извините, нонсенс - использовать в дискуссиях термин в том смысле, в котором его не использует практически никто - да еще и строить на этом надуманные претензии к фразам других.
Я, конечно, прекрасно понимаю, что Вам лично может нравиться использовать термин "системное программирование" соответственно тому, как он там Вам слышится...
Но, увы, увы, - в ИТ есть десятилетиями устоявшаяся терминология, в которой термин имеет другое, предельно конкретное, значение - и оно не совпадает с Вашим.

По поводу создания систем... Для создания ПРОГРАММНЫХ систем Оберон лучше многих языков, потому что система состоит не только из связей сверхвысокого уровня (которые, как Вы справедливо заметили, строятся на надъязыковом уровне), но и из отдельных компонентов. Если некоторый язык позволяет реализовывать каждый компонент системы и каждую отдельную связь в ней лучше, чем многие другие, то и для создания систем он будет подходить лучше.
Попробуйте построить систему из элементов, которые сделаны внешне в полном соответствии с интерфейсами, но внутри нашпигованы ошибками. Как бы прекрасно не была продумана вся Ваша система в целом, но в один прекрасный момент она рухнет из ошибки в единственном гнилом компоненте, созданном единственным из многих разработчиков на конкретном гнилом языке программирования вроде того же Си...

Ответ на »сообщение 4017« (Илья Ермаков)
___________________________
>> Увидели?.. О каком модуле Вы говорите?.. Нет еще никаких модулей, даже в проекте нет, а Вы уже что-то там импортируете... Откуда?..
> Если "никаких модулей" в проекте еще нет, то ничего вообще и не импортируем :-) И импорт Вам на этом этапе мешать не будет.
Совершенно верно...

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

А описание спецификаций ведется в разных модульных языках по-разному. В той же Аде мы пишем отдельную конструкцию package is ... end; помещаемую в отдельный файл ads (Ada Specification). Еще никакой реализацией (package body...) и в помине не пахнет, а мы уже можем компилировать спецификации, импортировать их друг другом - и тем самым проверять их совместимость и непротиворечивость.
Это очень полезно... на первых порах... по крайней мере. Потом понимаешь, что даже в больших системах интерфейсы крайне просты.

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

На этапе специфицирования пишутся просто "заглушки", а двоичные файлы спецификаций создаются автоматически компилятором. Но разделение на спецификацию и реализацию от этого не исчезает.
Так где же в этой схеме нарушение любимого Вами системного подхода?
Нарушение? Не вижу... А где в этой схеме Оберон?..

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

Я не отрицаю полезность модулей, но для декларирования при моделировании мне никакие модули не нужны... Нужен инструмент, который проводит это описание через все стадии проектирования, разработки, тестирования и эксплуатации. Это не языковые (в смысле, не 3GL) средства, я об этом с самого начала говорил...

Ну вот, наконец-то проступает ясность. Тезис о квалифицирующем импорте был просто предлогом поговорить на тему системности в ветке по Оберонам. Офтопик под благовидным предлогом с недомолвками, интригами и попутными обвинениями.

Языки программирования (языковые средства) для системности в понимании ASU не нужны. Оберон, не-Оберон, какая разница. Речь с самого начала шла не о языке. Но те неязыковые средства, которые имеет в виду ASU, на чем-то в конечном счете реализуются. Их можно делать на Обероне (если нет -- с интересом выслушаю контраргументацию), на каком-то другом языке. Т.е. претензии к Оберону в этом контексте абсолютно надуманы и преследовали вполне понятную теперь цель.

Ответ на »сообщение 4012« (Сергей Тарасов)
___________________________
я сторонник "сетевых структур с горизонтальными связями", а не корпораций. По жизни :) ИМХО, на таком уровне искусства декомпозиции личные пристрастия начинают накладывать отпечаток.
Не поверите... я тоже... за "сетевые" структуры. Все последние системы строил именно так: распределенные, слабосвязные, с произвольным числом подсистем. (И нет здесь никакого противоречия)...

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

Ответ на »сообщение 4005« (Илья Ермаков)
___________________________
Увидели?.. О каком модуле Вы говорите?.. Нет еще никаких модулей, даже в проекте нет, а Вы уже что-то там импортируете... Откуда?..

Если "никаких модулей" в проекте еще нет, то ничего вообще и не импортируем :-) И импорт Вам на этом этапе мешать не будет.

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

А описание спецификаций ведется в разных модульных языках по-разному. В той же Аде мы пишем отдельную конструкцию package is ... end; помещаемую в отдельный файл ads (Ada Specification). Еще никакой реализацией (package body...) и в помине не пахнет, а мы уже можем компилировать спецификации, импортировать их друг другом - и тем самым проверять их совместимость и непротиворечивость. А уже затем начинаем писать реализации в этим спецификациям. При этом элементы системы ничего не знают друг о друге, кроме того, что записано в спецификациях. В Обероне с целью минимализации отдельные файлы исходного кода спецификаций отсутствуют. На этапе специфицирования пишутся просто "заглушки", а двоичные файлы спецификаций создаются автоматически компилятором. Но разделение на спецификацию и реализацию от этого не исчезает.
Так где же в этой схеме нарушение любимого Вами системного подхода?