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

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

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

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

В том числе, препятствуя произволу верхних уровней.
Так сказать -- "тирании". :)
Нет, ни коем образом это не препятствует.

Почему не препятствует?
Если определенный инвариант инкапсулирован в соответствующем модуле, то другие модули не могут его "обойти", хоть тресни.
Значение этого факта для обеспечения надежности -- огромное.

>>>Сижу и думаю... А надо ли?..

Пока есть сомнения, лучше подождать (IMHO).

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

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

Согласен.
Но важно обеспечить надежность "на стыках".
Вот мы и "нудим" о раздельной компиляции. :)

В Обероне архитектура призвана поддерживать расширяемость системы (в принципе -- неограниченную).
Любимое Вами "буйство жизни". :)
Нет... Это не любимое мной... Мы слишком различно (как я понимаю) воспринимаем мир... Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом... В Обероне «буйство жизни» - это делай (на уровне модулей) все что хочешь... захотел импортировать – импортируй, захотел экспортировать – экспортируй (вдруг кому-то зачем-то сгодится!)... Анархия... За моим окном... все не так... Все, что там есть – электроны, протоны и нейтроны... все остальное величайшее искусство (многоуровневой) композиции основанное на простых, но строгих законах. И свою задачу мы, наверное, видим различно... для Вас (надеюсь я ошибаюсь) важно повторить многообразие, для меня... освоить искусство композиции... :)

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

>>>Хм?.. Я уже пообещал создать отдельную тему и там рассмотрю... не прикладной пример, если не будет возражений, разумеется.

Возражений нет. :)

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

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

Думаю, проще различать (если это зачем-то нужно) так:
1. для программы важен результат
2. для системы важен процесс

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

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

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

Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом...

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

Люди, не ссорьтесь!
Не станем доказывать, что правы именно мы, а во всем виноваты злокозненные оппоненты. :)
Давайте лучше начнем с чистого листа, и не станем повторять старых ошибок!

(Это просто мысли вслух.)

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

Случай конешно вырожденный, но блок-схему нарисовать проблем нет.
И если это не алгоритм то что?

Конечность является формальным признаком алгоритма.
http://ru.wikipedia.org/wiki/Алгоритм
Так что это просто ошибка. :)