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

прям черный пиар...

Большое спасибо уважаемому 1 за проведение независимой экспертизы.
Добавлю, что все остальные обвинения со стороны РБ так же ложны, как и проверенные, и построены по той же схеме -- фантастическое домысливание каких-то конкретных обстоятельств.
Никаких стоящих предложений о "кооперации" со стороны РБ не было, никакой заслуживающей внимания критики он не высказывал (в качестве свидетеля сошлюсь на Елену Филиппову, втроем с которой мы имели неформальное совещание по итогам визита Вирта-Гуткнехта).

Меня в основном беспокоит, что уже есть два примера, как "что-нибудь, да прилипает".
Второй -- в том же »сообщение 54« (~если так, то плохо).
Первый был в Мыслях-2 (шум вокруг других Оберонов, мол, конечно может не нравиться).

Я устал "отмазываться" от обвинений РБ. И в качестве последнего замечания предлагаю вопрос: CUI BONO? И тут возникает гипотЕза:
А не на содержании ли московского офиса M$ состоит РБ?Вот тогда все становится на свои места ;-)

Ответ на »сообщение 84« (Mirage)
___________________________
Просто для конкретизации. О  каком формате обероновских документов вы все рассуждаете? Их по крайней мере четыре и все они концептуально разные. Без точного указания о каком формате идет речь все рассуждения бессмысленны.
И еще раз о системе контроля версий - это актуально только для Blackbox - в остальных средах во эти средства есть.

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

Попробую систематизировать мои мысли о Оберон-документах. Мысли оформлены в виде утверждения о оберон документе и его сравнения с двумя другими технологиями, активно использующими понятия документ: XML-документ и Office-документ.

Читал, что это практически одно и тоже. В смысле, например, вордовский .doc внутри представляет из себя XML-документ. Только сохраняется не в текстовом виде, а в бинарном. Видимо чтобы сложнее было работать с ними всяким OpenOffice'ам и прочим конкурентам.

Вообще, если эта систематизация нужна для того, чтобы привести Обероновкие документы к виду, пригодному для систем контроля версий, не теряя при этом возможностей, то можно сразу сказать, что XML вполне подходящий формат.

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

Только обероновская версия является типобезопасной (type-safe).
И здесь большое значение имеет реализация расширения типа в Обероне.
Каждый тип записи в Обероне имеет свой уровень расширения.
Дескриптор типа содержит небольшой массив указателей на дескрипторы базовых типов.
Благодаря этой маленькой хитрости, динамическое определение типа (v IS T) в Обероне требует всего одного сравнения.

Я использую именно этот механизм сообщений (в Delphi). И кстати начал еще до прочтения Programming in Oberon. Привлекла меня к нему типобезопасность и вечная путаница с MSG_ID'ами у "обычных" сообщений.
Оператор IS в Обероне проверяет является ли тип v типом T, либо унаследованным от T. Тут одним сравнением врядли можно обойтись. Или упомянутая Вами хитрость как раз это и позволяет? Так в любом случае это зависит от реализации.
Гораздо уместнее (да и безопаснее, если есть иерархия сообщений) пользоваться оператором WITH.

Согласитесь, для динамического определения типа -- это очень эффективно.
Т.е. в языке Обероне мы имеем надежный (type-safe) и эффективный механизм для поддержки технологии программной шины.

С эффективностью было бы лучше, если бы для определения типа сообщения можно было бы использовать оператор CASE. К сожалению, ни в Delphi, ни в Обероне это невозможно, хотя при большом количестве сообщений это может быть заметно эффективнее.

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

Попробую систематизировать мои мысли о Оберон-документах.


Забыл сделать вывод. Оберон документ не очень удобен для построения на его основе систем документооборота. Причем не только из за его формата хранения.
1) Документ способен меняться непредсказуемым образом. Так считывание и последующее сохнанение само по себе достаточно, для того, что бы документ изменился.
2) Его внешнее отображение на прямую не связано с содержимым его файла, его вид вполне может меняться в зависимости от времени запуска например.
3) Документ не самостоятелен (не selfcontained), т.к. его отображение зависит от внешних (по отношению к нему) модулей с кодом, а так же модулей, которые они импортируют. Например при этом не понятно, на что ставить электронную подпись.

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

>>>Документ-ориентированная система программирования
С этого места пожалуйста поподробнее. Я давно и уже безнадежно ищу строгое определение понятия "документ".
"Это все равно что стакан кому-нибудь описывать или,  не  дай  бог,
рюмку: только пальцами шевелишь и чертыхаешься от полного бессилия." (с) Стругацкие.
Разработчики XML здорово продвинулись разделив понятия структуры, формы и содержимого документа, но и там больше "шевеление пальцев", чем строгие определения.
Если разговор зашел о документ-ориентированной системе, значит есть некоторая теория. Можете процетировать из нее определение документа? 


Попробую систематизировать мои мысли о Оберон-документах. Мысли оформлены в виде утверждения о оберон документе и его сравнения с двумя другими технологиями, активно использующими понятия документ: XML-документ и Office-документ. Причем под Office документом я буду подразумевать "классический" документ MS Офиса (возможно композитный с поддержкой технологии OLE), а не более современные тенденции вроде OpenOffice.

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

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

3) Формат документа не предназначен для анализа и модификации.
Документ "по настоящему" существует лишь в виде объектной модели в памяти компьютера. Нет централизованного знания о формате сохранения каждого элемента документа, каждый элемент документа сохраняет себя сам.
Офис-документ - аналогично.
XML-документ - существует стандарт как на объектную (DOM), так и на сериализованную структуру документа с однозначным отображением между ними.

4) Документ интерактивен и может содержать динамические элементы.
Для функционирования элементов, в системе должны присутствовать модули, содержащие их код.
Оффис - аналогично, взаимодействие между объектами документ более ограничено.
XML - сам по себе пассивен, но может быть интерактивным при его интерпретации (например веб-браузером).

5) Документ - часть системы, обладающая свойством "персистентности" (на это определение меня навело сообщение Руслана Богатырева).
В другой формулировке - документ ограничивает множество объектов системы, которые должны сохраняться и восстанавливаться вместе.

Получилось сыровато. Надо обдумать более подробно. Похоже тема заслуживает отдельной ветки.

Ответ на »сообщение 64« (Alexey Veselovsky)
___________________________


Собственно не имея защиты памяти, мы создаем прям таки рай для всяких кулхацкеров. То что запускаемый модуль вроде как не импортирует SYSTEM еще не означает что в нем не используется адресная арифметика, что он не напакостит в память. Ибо бинарник после компиляции можно и ручками подправить. И убрать упоминание о SYSTEM.

Т.о. без защиты памяти система крайне уязвима для: 1)Ошибок. 2)Преднамеренного вредительства.

Все познается в сравнении. Главной дырой в безопасности большинства систем является возможность переполнения буфера. В Обероне его нет в принципе. Вообще при таком подходе придется ограничиться только микроядерными архитектурами. (Хотя я не верю и в их абсолютную надежность... При первом знакомстве со мной QNX умер минут через 5 ;-) )

Без SYSTEM адресная арифметика использоваться не может.

На счет бинарника все несколько сложнее. Например slim-бинарники Франца содержат высоко-уровневую информацию о типах и области видимости переменных. При попытке обойти правила языка правкой бинарника приведет к тому, что он просто не откомпилируется. Последнее я на практике не проверял, но точно, что часть своих исследований Франц посвятил промежуточным форматам представления данных, на которых невозможно выразить неправильную программу.

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

Т.е. эпиграф "Make it as simple as possible, but not simpler" (он же известный KISS-principle или "принцип Калашникова") точно выражает подход Оберона. :)


В Церновской лекции Гутхнехт сказал, что понятие purity характеризует Оберон лучше, чем simplicity.

Так что не все так просто ;-)

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

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

Уважаемый AVC, раньше не смог передать мысль, попробую другими словами :-)

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

Также предлагаю к ОТ отнести способ конструирования языка и компилятора -- легкость подстройки того и другого под специальные приложения есть важно.


Мне кажется есть существенное отличие между простотой Оберона и простотой Лиспа и Форта. Они все опираются на простые базовые концепции, но гибкость Лиспа и Форта опирается во многом на изменении семантики синтаксических конструкций (макросы, компилирующие слова). Граница между языком и библиотеками при этом "размывается". В Обероне же разделение базовые средства/расширения очень четкое.

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


Потому что избыточная сложность есть уязвимость.

Вот это-то и есть, кстати, принцип Калашникова.

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

А почему "избыточная сложность есть уязвимость"?