Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4296 Удалено модератором | |
№ 4295 22-04-2007 07:21 | |
Ответ на »сообщение 4291« (Руслан Богатырев)
___________________________
Показывать в очередной раз, что эти схемы с точки зрения обеспечения абстрагирования равноправны, а с точки зрения надежности (контроля языка) -- разные, IMHO бессмысленно. Всегда будут желающие получить якобы бОльшую гибкость за счет надежности. Это их выбор.
В общем, получается что-то вроде того.
ASU как бы за неограниченную гибкость, мы за гибкость+надежность.
ASU, вероятно, с этим не согласится -- точки зрения у нас несколько разные.
№ 4294 22-04-2007 07:10 | |
Ответ на »сообщение 4293« (ASU)
___________________________
В том числе, препятствуя произволу верхних уровней.
Так сказать -- "тирании". :)
Нет, ни коем образом это не препятствует.
Почему не препятствует?
Если определенный инвариант инкапсулирован в соответствующем модуле, то другие модули не могут его "обойти", хоть тресни.
Значение этого факта для обеспечения надежности -- огромное.
>>>Сижу и думаю... А надо ли?..
Пока есть сомнения, лучше подождать (IMHO).
№ 4293 Удалено модератором | |
№ 4292 22-04-2007 06:53 | |
Ответ на »сообщение 4283« (ASU)
___________________________
Вы же не станете отрицать, что есть области, где функциональные языки или языки логического программирования позволяют проще и красивее решать задачи, по сравнению императивными языками. И если на каждом уровне вместо использования ложка-грабли-молотка (универсального инструмента) применять адекватные средства разработки, то надежность от этого только выиграет. Согласны?
Согласен.
Но важно обеспечить надежность "на стыках".
Вот мы и "нудим" о раздельной компиляции. :)
В Обероне архитектура призвана поддерживать расширяемость системы (в принципе -- неограниченную).
Любимое Вами "буйство жизни". :)
Нет... Это не любимое мной... Мы слишком различно (как я понимаю) воспринимаем мир... Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом... В Обероне «буйство жизни» - это делай (на уровне модулей) все что хочешь... захотел импортировать – импортируй, захотел экспортировать – экспортируй (вдруг кому-то зачем-то сгодится!)... Анархия... За моим окном... все не так... Все, что там есть – электроны, протоны и нейтроны... все остальное величайшее искусство (многоуровневой) композиции основанное на простых, но строгих законах. И свою задачу мы, наверное, видим различно... для Вас (надеюсь я ошибаюсь) важно повторить многообразие, для меня... освоить искусство композиции... :)
Думаю, что многообразие и искусство композиции -- две стороны одной медали.
"Анархия" же импорта/экспорта в Обероне весьма ограничена.
Например, ацикличностью модульной структуры (модули образуют DAG).
Главное достоинство модулей -- они позволяют инкапсулировать те или иные аспекты поведения системы.
В том числе, препятствуя произволу верхних уровней.
Так сказать -- "тирании". :)
>>>Хм?.. Я уже пообещал создать отдельную тему и там рассмотрю... не прикладной пример, если не будет возражений, разумеется.
Возражений нет. :)
№ 4291 22-04-2007 06:52 | |
Ответ на »сообщение 4288« (AVC)
___________________________
Если под программой (в отличие от системы) понимать реализацию алгоритма, то о каком числе алгоритмов идет речь (один -- программа, два и больше -- система)? Если программа обладает интерактивностью (не пакетная обработка), то ее нужно считать системой или это все же программа?
Думаю, проще различать (если это зачем-то нужно) так:
1. для программы важен результат
2. для системы важен процесс
Боюсь, все эти рассуждения нас мало куда приведут (сходимость процесса обсуждения для меня неочевидна). Ведь тема деления на программы и системы была инициирована ASU в %4158 с простой целью -- убедить, что Оберон подходит для написания программ и не подходит для написания систем. Точнее, не подходит для " правильного" создания систем по-ASU.
Думаю, самое простое -- согласиться с этим тезисом и поставить здесь точку. Оберон не подходит для "правильного" создания систем по-ASU. По одной простой причине: он описывает связи сущностей с интерфейсом именно в языке (импорт), а не вне языка (автоматическое коммутирование связей и разрешение коллизиций). Показывать в очередной раз, что эти схемы с точки зрения обеспечения абстрагирования равноправны, а с точки зрения надежности (контроля языка) -- разные, IMHO бессмысленно. Всегда будут желающие получить якобы бОльшую гибкость за счет надежности. Это их выбор.
№ 4290 22-04-2007 06:45 | |
Ответ на »сообщение 4283« (ASU)
___________________________
Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом...
Ну всё... пошёл-ка я на улицу, в то самое буйство жизни, пока не свихнулся окончательно от этого (да и других) форума... :о(
№ 4289 22-04-2007 06:36 | |
Люди, не ссорьтесь!
Не станем доказывать, что правы именно мы, а во всем виноваты злокозненные оппоненты. :)
Давайте лучше начнем с чистого листа, и не станем повторять старых ошибок!
(Это просто мысли вслух.)
№ 4288 22-04-2007 06:24 | |
Ответ на »сообщение 4285« (MS)
___________________________
Случай конешно вырожденный, но блок-схему нарисовать проблем нет.
И если это не алгоритм то что?
Конечность является формальным признаком алгоритма.
http://ru.wikipedia.org/wiki/Алгоритм
Так что это просто ошибка. :)
№ 4287 Удалено модератором | |
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|