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

Когда я утверждал, что ПРОГРАММУ удобно проектировать прямо на языке программирования, мне начинали объяснять про UML и прочие специальные инструменты.
Когда я говорю, что СИСТЕМУ неудобно проектировать прямо на языке программирования, мне говорят, что никакие дополнительные инструменты не нужны.
Ну куды бедному крестьянину податься :(

Для этого бедному крестьянину стоит призадуматься о применимости обоих подходов, выявляя контекст применения инструмента:
1. кустарное или промышленное производство ПО
2. условия исполнения проекта (требования, ресурсы, квалификация/опыт, сроки и т.п.)

Ответ на »сообщение 4263« (Руслан Богатырев)
___________________________
>>>Она реализует простой алгоритм, но подпадает под Ваше определение отличия программы и системы и трактуется как система.
Процедура реализует алгоритм ввода символа.
А система поддерживает ввод с клавиатуры.

Ответ на »сообщение 4258« (AVC)
___________________________
>>>...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
Самое забавное, что в различных ветках от одних и тех же людей можно получить противоположные возражения :)
Когда я утверждал, что ПРОГРАММУ удобно проектировать прямо на языке программирования, мне начинали объяснять про UML и прочие специальные инструменты.
Когда я говорю, что СИСТЕМУ неудобно проектировать прямо на языке программирования, мне говорят, что никакие дополнительные инструменты не нужны.
Ну куды бедному крестьянину податься :(

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

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

Простой контрпример: я пишу процедуру P, которая считывает ввод одного символа с клавиатуры, вычисляет его код по таблице (допустим ASCII), отображает код в диапазон от 0 до 9 (операция MOD 10) и выводит на экран итоговую цифру. Эта процедура работает в бесконечном цикле и помещается в модуль M. Она реализует простой алгоритм, но подпадает под Ваше определение отличия программы и системы и трактуется как система.

Не в этом деле. Совсем не в этом.

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

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

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

Не поленитесь еще раз перечитать »сообщение 4173«, чтобы убедиться в том, что упрек в работе только на передачу, но не на прием (т.е. не слыша оппонентов) я уж никак не мог адресовать в адрес себя любимого.

Руслан, ситуация абсолютно симметричная, Ваши ответы тоже не о том :)

Безусловно. Я совершенно напрасно подробно объяснял (и все время не о том):
1. что такое квалифицирующий импорт в Обероне
2. что такое импорт вообще и чем принципиально отличается раздельная компиляция от независимой
3. что импорт в Оберонах реализуется исключительно через интерефейсы
4. что некорректно сопоставлять средства архитектуры (методологии) с реализацией (универсальным языком программирования), особенно тому, кто согласен с тезисом об инвариантности методологии относительно языка программирования.

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

Случай 1 -- это отсутствие абстрагирования ("по-живому" без наркоза)
Случай 2 -- это наличие абстрагирования (интерфейс)
Случай 3 -- это вынесение описания отношений в отдельную область (но эти отношения все равно должны будут оперировать поименованными сущностями на другом уровне абстракции).

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

Оберон предлагает достаточно прозрачную схему:
1. Модуль -- это главная сущность для формирования элементов системы.
2. Интерфейс модуля -- это механизм абстрагирования (отделения внешнего представления от внутреннего).
3. Экспорт -- это отображение вида "модуль --> интерфейс"
4. Импорт -- это отображение вида "интерфейс --> модуль"
5. Межмодульные связи в языке выстраиваются через интерфейсы (и только через них). Они строятся на отношении импорта.
6. Межсущностные (межъэлементные) связи в языке регулируются как межмодульными связями, так и межклассовыми связями (отношения между расширяемыми типами-классами).

Язык Оберон де-факто создавался как язык реализации Oberon System (операционной системы).  Мне трудно себе представить какую-то программную систему, которая по своей архитектурно-инженерной сложности превосходила бы этот класс задач (ибо в ней все равно будет решаться задача обеспечения взаимодействия элементов, распределения ресурсов и управления применительно к исполнению на компьютере).

Можно рассуждать о том, подходит или нет язык Оберон/КП в качестве языка проектирования. Простите, а почему он должен обязательно подходить для целей, для которых не создавался? Проектируйте другими средствами, на других языках (не 3GL) и отображайте хошь на языки 3GL, хошь на операционные слои (выполненные в итоге на них же). Можно ли в принципе проектировать на сущностях и языковых средствах Оберона (модули, интерфейсы, экспорт-импорт)? Да, можно. У меня лично в этом сомнений нет.

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

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

Сомневаюсь насчет "функционального стиля", остальное -- верно.
Команды были в Оберон-системе изначально и являются одним из важных условий ее расширяемости.
IMHO, у Мессенбека была простая, но очень неплохая статья о расширяемости в Оберон-системе:
http://www.oberon2005.ru/paper/p_ext.pdf
В ней значительное место уделено командам.
Важно, что команды очень тесно интегрированы с модулями.

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

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

Мультиязычность систем может иметь один конкретный недостаток: недостаток надежности.
По крайней мере, раньше мультиязычность была основана на независимой компиляции и безразличии линкера к типам. Линкеру все едино: ЯВУ и ассемблер.
Раздельная компиляция надежна, но требует некоей единой основы: одного ЯВУ (оригинальная Оберон-система) или одного промежуточного языка (.NET).

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

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

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

>>>Руслан Богатырев назвал режим общения полудуплексным, мол он чужое читает, а его ответы то ли не читают, то ли не понимают. Руслан, ситуация абсолютно симметричная, Ваши ответы тоже не о том :)

Ох, Сергей, все еще более симметрично... :)
Не помню как у Крылова. Примерно так:
...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
:)

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

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

Если не ошибаюсь, известно, что область применения ООП шире, нежели обобщенного программирования.
С помощью ООП всегда можно добиться того же, что и с шаблонами (конечно, иногда это может выглядеть несколько искусственно), обратное же неверно.
В принципе, шаблоны необязательны, но я к ним привык в Си++... :)
Что касается "кластеров" (Руслан Богатырев), то поддержка языка все-таки, наверное, желательна.
Я имею в виду (очень :) ) большие программные комплексы.

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

В статье "Oberon vs. C++" (1994) Йозеф Темпл высказал ту же мысль:
In principle, a template preprocessor would also be possible for Oberon, however, as a separate tool.
http://www.oberon2005.ru/paper/p_obecpp.pdf (eng)
http://www.oberon2005.ru/paper/templ.pdf (рус)
Это возможно, но меня давно смущает, что была все-таки сделана попытка "внедрить" дженерики в Оберон.
Я имею в виду старую работу Роу и Шиперски о легковесном параметрическом полиморфизме для Оберона (примерно 1997).