Ответ на »сообщение 4243« (Антон Григорьев)
___________________________

Нет, главный местный критик модульного программирования
А теперь приведите хоть одну цитату, где я критикую модульное программирование... Ха-ха-ха-ха...

Ответ на »сообщение 4238« (AVC)
___________________________
Что касается концепций, то существуют теории (например, та же ТРИЗ), что искусственные системы развиваются за счет преодоления противоречий, повышая свой "уровень системности" (переходя в надсистему) и т.д.
Я это к тому, что на практике нет какой-то абсолютной системности, всегда есть "куда стремиться". :)
А вот у Вас, возникает впечатление, ОТС представляется таким достигнутым раз и навсегда "идеалом", которому остается только подражать.
Хм?.. Вы помните старый добрый BASIC, в котором не было не структур данных, ни подпрограмм... Зато было много любителей этого «простого» языка. Им также трудно было доказать, что структурирование кода и данных полезно. «Зачем?», - восклицали они: «Мне надо решить небольшую задачку, и я ее могу быстро решить на BASIC...». И они записывали код «сплошняком», обрамляя комментариями те участки, которые по-хорошему надо было бы вынести в подпрограммы... «В строках 350-420 выполняется преобразование...». Помните?. И, в общем-то, были правы... только задачки со временем росли, объединялись... Программы переписывались и... приходили в негодность, поскольку не обеспечивали нужного (к этому времени) функционала, а переписывать и развивать это безобразие уже не было возможностей. Являлись тогда требования структурного программирования абсолютом? Наверное, нет... но они реально позволили создавать большие программы, более быстро и качественно. «Проклятие размерности» отступило... на запасные позиции.

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

Но улучшать Оберон надо вдумчиво, а не просто добавляя "полезные" конструкции, которые впоследствии окажутся "минами замедленного действия".
Когда я предлагал улучшать Оберон?.. Если вспомнить, то я ратовал за мультиязычность систем...

Что касается требований структурного программирования и системного подхода, то между ними есть связь.
Безусловно, но не только (и не совсем та) связь, о которой Вы говорите.

Ответ на »сообщение 4240« (Илья Ермаков)
___________________________
Разговор о неверной формулировке тезиса "импорт в модульных языках противоречит системному подходу". Правильнее сказать - для больших систем со многими слоями сам по себе импорт не дает способа управлять сложностью, требуются дополнительные надъязыковые средства.
Нет, все правильно... именно противоречит... В Обероне любой модуль может импортировать все, что экспортировано другими модулями, нет ни каких ограничений... Соответственно, и экспортировать модуль может любые свои «потроха»... опять же без каких либо ограничений. При разработке систем – это недопустимо (по крайней мере, моветон).
Есть архитектура системы, которая создается «архитекторами» (аналитиками) и уточняется  проектировщиками. Именно здесь закладываются уровни и интерфейсы. Программист использует эти решения не имея ни малейшего права вмешиваться в них. Когда он пишет код, то он либо реализует интерфейс заложенный архитектором/проектировщиком, либо использует интерфейс нижнего уровня, опять же заложенный на предыдущих стадиях. Предположим, что в данной системе интерфейсы реализуются через подпрограммы и на данном уровне объявлен интерфейс A... Если программист написал:

SUBROUTINE A...

, то он явно говорит о том, что в данном месте начинается реализация интерфейса A. Зачем объявлять экспорт? Если работая на другом уровне тот же или другой программист написал:

CALL A

, то он обратился к интерфейсу A. Зачем нужен импорт? Предположим, что он написал и свою подпрограмму и решил ее назвать тоже A. То система должна указать ему, что на данном уровне этот интерфейс может только использоваться, но не реализовываться.
Далее, предположим, что на обоих уровнях есть интерфейс A. Тогда написание подпрограмм с именем A на каждом из уровней – есть реализации интерфейса А. И обращение к интерфейсу А приведет к обращению интерфейса А нижнего уровня, поскольку, как уже многократно говорилось, никакие связи на одном уровне недопустимы. Никакого конфликта не возникает. Можно на одном уровне делать несколько реализаций одного и того же интерфейса...
Понятия экспорта и импорта совершенно излишни... искушение одним словом.

PS. Господа, я готов отвечать на Ваши вопросы, но давайте рассматривать вопросы создания систем в отдельной теме.

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

Ответ на »сообщение 4238« (AVC)
___________________________
Пакеты ("кластеры") модулей точно также можно организовать внешним инструментом вроде Cabal в Хаскелле, который может организовывать наборы модулей в легко отчуждаемые пакеты со строго специфицированным интерфейсом и указаниями по зависимостям от других пакетов...
Разве трудно всё это сделать для Оберонов?
Да нет, не сложно. Можно и нужно.
Однако пакеты - это нечто другое, нежели кластеры. Пакет - это единица дистрибуции/инсталляции.

Кластер - это конструктивная связка модулей...
Кстати, идея. В Компонентном Паскале есть такое понятие, как подсистема. Т.е. нечто вроде "кластера". Однако внешним интерфейсом такого кластера по умолчанию являются интерфейсы всех его модулей. Т.е. есть повод для критики - сторонний кластер может легко импортировать некоторые внутренние модули нашего кластера и завязать ненужные связи.
Тут два случая - open-source и не-open-source. В первом никакими силами запретить такие связи нельзя.
А вот во втором - запросто. Из подсистемы просто вырезаются sym-файлы для всех ее внутренних модулей. Т.е. предоставляем спецификации только на наружний интерфейс подсистемы, а на все внутренние - нет. Без наличия спецификации импортировать модуль низя :-)

Ответ на »сообщение 4240« (Илья Ермаков)
___________________________

Разговор о неверной формулировке тезиса "импорт в модульных языках противоречит системному подходу". Правильнее сказать - для больших систем со многими слоями сам по себе импорт не дает способа управлять сложностью, требуются дополнительные надъязыковые средства.

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

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

При этом ASU пишет "Модули я не критикую, а приветствую, благодаря им осмысливается и соблюдается инкапсуляция". С учётом этого всё становится ещё интереснее: оказывается, модули - это не столь однозначное зло, как goto, их до определённой степени можно использовать. Тогда уместно говорить о границах применимости - о том, какой критерий определяет, когда нужно использовать модули, а когда - ещё не названную альтернативу. С обоснованием этого критерия. Это тоже могло бы оказаться очень интересным.

Итак, чтобы дальнейший разговор не был пустой тратой времени, надо, чтобы была изложена вполне конкретная альтернатива модулям и описано, когда и почему эта альтернатива лучше. Вот только не вижу я смысла задавать такие вопросы ASU - заранее знаю, что внятного ответа не будет. В посему и говорить не о чем.

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

... не утрирую я... Просто надо перенести этот разговор в другую ветку...


Давно пора ...

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

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

И обобщённое программирование, и "кластерно-модульное программирование" вовсе не требуют расширения языка. С расширениями, конечно, удобнее и понадёжнее, но и без них можно.

Для обобщённых модулей/процедур/типов вполне можно приспособить какой-нибудь простейший препроцессор/макропроцессор, расширив его контролем типов/разрешений доступа и т.д.

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

Разве трудно всё это сделать для Оберонов?

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

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

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

Что значит «равноценное» средство? Если в Обероне можно импортировать модуль, и обратиться к любой (экспортируемой данным модулем) подпрограмме или переменной, то, строго говоря, это уже нарушение (или не строгое соблюдение) инкапсуляции.

В Оберонах подобные недостатки легко (как я понял) устраняются пакетированием модулей в отдельные Оберон-системы. Например, делаете разные подсистемы в разных копиях того же Блэкбокса и связываете их (подсистемы) по сетевому протоколу или COM-интерфейсам...

Внутри подсистем связи сильные (так как это необходимо для эффективной работы), между ними - слабые... В чём проблема-то?

PS. Ежели действительно в такой модели есть недостатки, надеюсь, наши оберонщики посвятят нас в них... :о)

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

>>>Нет, не только... Основное различие на концептуальном уровне, все остальное - следствия...

Что касается концепций, то существуют теории (например, та же ТРИЗ), что искусственные системы развиваются за счет преодоления противоречий, повышая свой "уровень системности" (переходя в надсистему) и т.д.
Я это к тому, что на практике нет какой-то абсолютной системности, всегда есть "куда стремиться". :)
А вот у Вас, возникает впечатление, ОТС представляется таким достигнутым раз и навсегда "идеалом", которому остается только подражать.
Но ни в одной области техники "идеал" не воплощен, везде есть свои противоречия и конфликты.

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

>>>Есть требования структурного программирования, и Оберон им соответствует, есть требования системного подхода, и Оберон им не соответствует.

Возможно, хотя все же непонятно, каким именно требованиям системного подхода не соответствует Оберон.

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

Что касается требований структурного программирования и системного подхода, то между ними есть связь.
Например, структурное программирование было одним из источников модульного программирования (другим источником было болезненное сопоставление с модульностью аппаратуры).
В данной ветке эта интересная связь отмечалась Русланом Богатыревым.
Ее можно усмотреть между методом нисходящего построения программ (поэтапное уточнение деталей -- Вирт) и модульностью, как сокрытием деталей (Парнас).

>>>Следовательно, существует очень небольшое количество «пространств имен», доступных элементу.

Небольшое количество больших "пространств имен"?
Что-то меня здесь смущает...

>>>Если в Обероне можно импортировать модуль, и обратиться к любой (экспортируемой данным модулем) подпрограмме или переменной, то, строго говоря, это уже нарушение (или не строгое соблюдение) инкапсуляции.

А почему это нарушение инкапсуляции?
Если бы речь шла о прямом обращении к неэкспортированной сущности, я бы с Вами согласился.
Здесь же обратная ситуация.
Если некоторые экспортируемые модулем сущности оказались никому не нужны, то вероятно имела место какая-то ошибка проектирования.

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

Конструкция модулей и межмодульных связей воспроизводит соотв. концепции железной техники. Автомобиль, например, является системой?
Да, конечно...

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