Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4306 22-04-2007 10:01 | |
сообщение от модератораЗа пререкания с модератором все сообщения ASU будут удаляться.
№ 4305 22-04-2007 09:53 | |
Ответ на »сообщение 4275« (Илья Ермаков)
___________________________
А полноценная параметризация в настоящий момент технически не вяжется с динамической модульностью. И "вязаться" она начнет только после одного события - перехода какой-либо из магистральных реализаций Оберонов (Ящика али Бутылки) на промежуточное представление Франца и JIT. Но пока до этого руки не доходят ни у них, ни у нас...
Это как Java чтоли? Дык она производительностью не блещет, хоть и оптимизировали они компилятор по самое нехочу. В смысле денег много в это вложили.
IMHO одно из достоинств Оберона в том, что он компилируется в нативный код. И теоретически (при наличии хороших компиляторов) можно получить высокое быстродействие.
Другое дело, что можно использовать это промежуточное представление без JIT. Для переносимости можно написать на C его интерпретатор и тогда везде, где будет С, будет и Оберон, пусть медленный. Для экспериментов с платформой сойдет.
А по мере необходимости и полноценный кодогенератор для данной платформы дописать можно.
№ 4304 22-04-2007 09:51 | |
Ответ на »сообщение 4302« (ASU)
___________________________
Ответ на »сообщение 4300« (AVC)
___________________________
Я попробую пояснить на другом примере. Если в базе данных таблица А ссылается на таблицу Б, то это не означает, что одна из таблиц «выше», а другая «ниже». Это просто связи на одном уровне... и все..
Если мы запрещаем таблице Б обратную ссылку на А, то есть, делаем связь строго однонаправленной. Если мы делаем связь однонаправленной, то подразумеваем, что ее участники неравноправны. Тот, кто импортирует, стоит в иерархии уровней системы выше того, кого импортируют.
И всегда, даже при отсутствии отдельного этапа проектирования, когда состав/структура модулей эволюционирует "методом проб и ошибок" (при "кустарном производстве" или в небольших проектах бывает и так) - слои системы четко выделяются. Есть более низкоуровневые группы модулей, есть более высокоуровневые - и все связи выстраиваются в одну сторону. И по-другому просто не получится - модульность с иерархическим импортом этому препятствует. А вот в языках без импорта хаосу не препятствует ничего. В языке с импортом, если вдруг внезапно "приспичит" сделать одноранговую перекрестную ссылку модулей, язык этого просто не позволит, и разработчик будет ВЫНУЖДЕН что-то перепроектировать, переделать - как бы ему ни хотелось сляпать на скорую руку, но компилятор неподкупен и твердо дает понять, что в архитектуре есть концептуальная ошибка. В языке без импорта будет сделана "быстрая клепка": A.cpp: include B.h, B.cpp: include A.h - и все так и покатится дальше...
Для примера. В Блэкбоксе есть такая штука DevDependencies - она показывает весь даг зависимостей, идущий от некоторого модуля, рисует графически, позволяет наглядно все "пощупать"...
Я построил даг, уходящий вверх от самого низкоуровневого модуля Kernel, и включающий в себя системные модули среды:
http://ermakov.metasystems.ru/forum/DependMap.gif
Связей много - но они не образует ничего похожего на клубок. Присутствует целый ряд слоев - и пучки "проводов", идущих с верхних слоев к нижним. Взаимодействия управляемы и в то же время эффективны, без излишней косвенности...
И это мы смотрим внутрь одной подсистемы. "Слоистость" на уровне подсистем среды еще более четкая.
При этом ББ именно пример "эволюции кластера модулей" - фактически, это многолетний эксперимент, переросший в промышленную среду... Сейчас уже видно, как можно улучшить структуру и еще более четко обозначить слои и связи...
Чтобы прочувствовать разницу между наличием в языке импорта и его отсутствием, достаточно хоть немного повозиться - даже не с исходниками! - с заголовками Линукса. Импорт в языке - это как раз-таки средство избежать "комбинаторного взрыва" зависимостей между частями программы. Средство, начинающее работать автоматически, независимо от желания или нежелания программиста, даже при написании "на коленках" программульки из четырех-пяти модулей.
№ 4303 22-04-2007 08:20 | |
№ 4302 Удалено модератором | |
№ 4301 22-04-2007 07:43 | |
Ответ на »сообщение 4299« (ASU)
___________________________
А есть какая-то связь между «плоское» и не на одном уровне? Какие уровни модулей поддерживает Оберон?.. точнее было бы спросить так, какие уровни модулей позволяет создавать и поддерживать Оберон?..
Просто представьте DAG (частный случай дага -- дерево).
По-моему, это иерархическая структура.
№ 4300 22-04-2007 07:39 | |
Ответ на »сообщение 4298« (ASU)
___________________________
Поясню... Много раз я говорил, что должны быть уровни. Это ограничение и ограничение жесткое. Много раз я говорил, что элементы (модули) одного уровня не должны прямо взаимодействовать друг с другом (должен быть, как минимум, контроль со стороны над-уровня). Это ограничение и ограничение жесткое. Эти ограничения обеспечивают надежность системы. «Вы» не поддерживаете эти ограничения... и, следовательно, отказываетесь от элементов обеспечивающих надежность, то есть, согласны на... безнадежность... :)
Здесь, возможно, какая-то терминологическая путаница.
Связь импорт-экспорт (т.е. прямое взаимодействие модулей) в Обероне всегда иерархическая (в логическом смысле -- нет "кругов в определении").
Если A определяется через B, то, IMHO, здесь сущности не совсем одного уровня.
№ 4299 Удалено модератором | |
№ 4298 Удалено модератором | |
№ 4297 22-04-2007 07:31 | |
Ответ на »сообщение 4296« (ASU)
___________________________
Это я вообще перестал понимать... в контексте предыдущего... тем более.
Если в Оберон все модули на одном уровне, то о каком верхнем уровне идет речь. Если в Оберон все модули на одном уровне, то их можно использовать как угодно (тирания, в том числе)... Где-то я потерял Вашу мысль...
Я никогда не говорил, что в Обероне все модули на одном уровне.
Если один модуль импортирует другой, то они не на одном уровне; это гарантируется ацикличностью связей импорта.
Я лишь немного сетовал на то, что "пространство имен" модулей в Обероне "плоское".
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|