Ответ на »сообщение 4143« (Jack Of Shadows)
___________________________

>>>Болото болтовни.

Заходите -- поквакаем. :)

Да, и еще...

Дабы поставить точку в "системности" импорта модулей.
Импорт в модульных языках может быть только иерархическим. Таким образом, вся статическая "связка" модулей образует дерево.
Рассматривайте всю цепь импорта от одного узла как систему. Срежьте этот узел - система распадется на подсистемы.
И наоборот.
У меня есть две подсистемы - сетевая с лицевым модулем Net и файловая с лицевым модулем Files.
Я создам новый модуль Server. В начале модуля Server я напишу IMPORT Net, Files.
В итоге я получаю новую систему более высокого уровня, в которую в качестве подсистем вошли Net и Files. А вся собственная логика системы "сервер" собрана в модуле Server.
Таким образом, импорт модулей куда как системен...
Каждый модуль в списке импорта - это подсистема данного модуля. Сам модуль включает в себя собственную логику новой надсистемы - и вместе со всем деревом импортированных модулей и образует эту новую надсистему.

Что лучше - выдать личному составу автоматы с подствольными гранатометами, или не выдать их (хотя они есть на складе) под предлогом того, что "метать гранаты из автомата - глупость. Автомат - он и есть автомат... А для гранат существуют минометы".

Посмотрим и с другой стороны. Вы не хотите и считаете вредным наличие "проектных" средств в языке. Да, это прекрасно - спроектировать систему в специализированных средах. Но доходит дело до реализации - и что же мы видим? Все богатство наработанных отношений и связей напрямую выразить в языке мы не можем... Вы как-то упоминали, что построение таких отношений и связей Вы предпочитаете писать отдельно, на скриптовых языках и т.п. Елки-палки, да неужели же это лучше, чем иметь аккуратный, строгий набор средств единого языка, в который легко отобразить все ваши наработанные "особыми инструментами" проекты?
Меня такие ставшие модными "мультиязыко-скриптовые" с позволения сказать "архитектуры" очень сильно раздражают. Напоминает нарезку деталей из трухлявой древесины корявого "основного языка", с последующей склейкой, уж извините, "соплями" всевозможных скриптов и скриптиков...

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

Кому что... Я предпочитаю "идеальную пригонку" универсального, строгого языка - дешевке mainstream-калейдоскопа...

Ответ на »сообщение 4141« (Илья Ермаков)
___________________________
Господа, вы уж меня извините, но появление ASU и его многословный поток сознания превратил эту ветку в очередные "Информационные Поля".
Последние несколько десятков постов я просто ниасилил. :))
Болото болтовни.

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

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

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

Теперь от 3GL...
Чем плохо введение в язык "системных" в Вашем понимании возможностей? Чем плохо, что программируя на Обероне, я несколько раз в день разбиваю с помощью модульной декомпозиции разрабатываемый сервис на отдельные "подсистемы", слои со строго специфицированными связями через "узкие горла"? Что вместо написания "монолита" я разбиваю на изолированные модули, связь между которыми выношу на отдельный уровень, уровень диспетчерских модулей - ну прямо "по ASU" :-)
Чем плохо, что каждый студент с самых первых занятий усваивает принципы таких архитектур?

Вы же предлагаете "элитарность системного подхода", когда рядовые разработчики как муравьи будут копошиться в хаосе вермишели на "бессистемных" 3GL, а "гуру" из отдела системного анализа будут применять "особые подходы", недоступные простым смертным? (я Вас не упрекаю в такой "злонамеренности", Боже упаси, я просто пытаюсь вскрыть противоречия вашей позиции).
Так что посеем, то и пожнем. Когда я захочу позаимствовать у стороннего разработчика небольшой компонент для Оберона, я получу, скорее всего, что-то весьма неплохо сконструированное и работоспособное. Просто потому, что на Обероне проще сконструировать аккуратно, чем неаккуратно... Вы же рискуете не найти ни одного компонента приемлемого качества (с теми же Сями в большинстве случаев так и есть) - просто потому, что НИ ОДИН отдельно взятый разработчик - небольшая группа разработчиков - не будет применять какие-то особые средства проектирования и стрелять из пушки по воробьям... Они применят то, что дает язык. Вы хотите, чтобы они так и продолжали использовать языки, которые не дают НИЧЕГО для грамотного конструирования? Так они и будут использовать! И чхать они хотели на все ваши "особые инструменты для проектирования систем"...

Что лучше - выдать личному составу автоматы с подствольными гранатометами, или не выдать их (хотя они есть на складе) под предлогом того, что "метать гранаты из автомата - глупость. Автомат - он и есть автомат... А для гранат существуют минометы".

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


Еще раз... Система имеет свою собственную логику. Реализация этой логики происходит через посредство «слабых» связей. Нет «слабых» связей – нет логики; нет логики – нет системы... просто пазлы...
Прекрасно. Человеческий организм - тоже не система? Нет "слабых связей", нельзя отделить руки-ноги, а потом присоединить обратно? Потому что соседние клетки могут взаимодействовать между собой напрямую, в обход ЦНС?
Биосфера - тоже не система, потому что нельзя отдельно взятого зайца выкинуть в космос - он там помрет?

Наткнулся в Интернете на статью Robert C. Martin "Design Principles and Design Patterns":
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
По-моему, хорошее и популярное изложение некоторых принципов объектно-ориентированного дизайна.
Некоторые принципы (OCP, DIP, ADP) очень близки Оберону.

Ответ на »сообщение 4096« (А.П.)
___________________________

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

Недостаточно. Здесь уже обсуждали пример олимпиадной задачки с последнего чемпионата мира ACM по программированию. Она была решена (вариант на КП) в виде программы (одного модуля).

Будьте так любезны, дайте ссылку

http://forum.oberoncore.ru/viewtopic.php?t=409

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

>>>Если я правильно понял ASU, интерфейс "вагончик--вагончик" относится к вагончикам и даёт состав, а "вагончик--рельсы" относится уже к составу (ну и его вырожденному случаю - одному вагночику) :-)

В любом случае, интерфейсов больше одного. :)

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

>>>Конвейер UNIXа и набор его утилит - простейший пример программной системы.

И хороший пример.
Оберон-система -- тоже простой пример программной системы.

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