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

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

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

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

Ответ на »сообщение 57« (Alexey Veselovsky)
___________________________
Не совсем понимаю суть вопроса.
Касаемо BlackBox: это же Windows-программа и она подчиняеется тем же правилам, что и любая другая Windows-программа.
Oberon System и Bluebotle действительно не защищены от  криво- и злонамеренно-написанных программ. Но даже если подключать аппаратную защиту, в  разделении адресных пространств нет никакой необходимости.
К тому же в этих системах нет виртуальной памяти, а значит, нет надобности иметь больше адресного пространства, чем физической памяти.

Предлагаю такой план действий. :)
Сначала мы все (скажем, в течение недели) составим и "утвердим" список основных механизмов ОТ, а затем станем исследовать эти механизмы более пристально.
В силу сложности детального изучения (Оберон, простой для прикладного программиста, не так уж прост внутри; чего стоят одни только тонкости раздельной компиляции и фингерпринтов), возможно, имеет смысл иногда разбиваться на группы.

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


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

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

Я тоже стараюсь подойти к формулировке этого важнейшего качества ОТ.
Т.е. интуитивно оно (почти) понятно.
Но хочется внятно для себя сформулировать, почему это так важно.
Что здесь, так сказать, Сцилла, а что -- Харибда. :)
Догадываюсь, что здесь есть родство и с обычными принципами структурирования программ (например -- once & only once у Бека в экстремальном программировании и т.д.).


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


В принципе согласен.
Сужу о подходе Вирта к построению языка и компилятора по его книге "Compiler construction" и любопытной статье Мессенбека (кажется, из книги "The art of simplicity"; или что-то похожее).
Ну, и, немного, -- по исходным текстам компиляторов Оберона и КП.
Единственное, что немного смущает, это сознательный отказ от значительной оптимизации и использования метода раскраски графа при распределении регистров. :)
(Взамен Вирт использует принцип delayed code emission.)
Но простота, несомненно, окупается.
А в случае slim binaries еще и дает неожиданные (?) дивиденды.

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

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

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

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

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

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

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

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

Еще на эту тему:
http://www.intuit.ru/department/se/pbmsu/5/

Ответ на »сообщение 66« (Андрей Хохлов)


Вполне возможно, что фраза вырвана из контекста, а буквальное ее толкование представляетс крайне сомнительным. А может просто хороший != великий.


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

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

Может кто-нибудь объяснить мне что означает слово "инвариант"? Я столько раз его слышал (например, инвариант цикла, инвариант памяти), а смысла не знаю.

http://ru.wikipedia.org/wiki/Инвариант

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


С первым понятно. Со вторым - нет. Сборки чего?

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


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

Конечно.
Но, ИМХО, для того, чтобы гарантировать инварианты памяти, необязательно отказываться от единого адресного пространства.
Проблему можно решать с помощью языковых средств -- ограничений промежуточного языка системы (как в .NET) или безопасной моноязычности (как в Обероне).


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

Бинарник можно защищать контрольными суммами (это может быть частью фингерпринта) или иными способами.
Другой подход -- slim binaries Франца.
Читал, что их загрузка всего на 10-20% медленнее объектных модулей.


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

И если первое еще как-то лечится запретом импорта SYSTEM для несистемных модулей, то второе уже не лечится.

Вы полагаете, что это лечится в других системах?


Ведь опасным может быть не только "падение" конкретной программы, но и неверное вычисление, и принятое вследствие этого решение и т.д.
Ну, если в модуле MATH, кто-то на функцию SUM повесил не а+б, а а-б, то тут уже ничего не поделаешь.

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


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

Думается, что именно все эти проблемы и привели к Active Oberon и Bluebottle.

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

Active Oberon, кроме прочего, добавил потоковую безопасность (thread-safe).