Мы часто говорим, что существует оригинальная Оберон-технология (дальше -- ОТ или ТО, как кому нравится :) ), имеющая свои особенности.
На этом форуме хотелось бы четко сформулировать эти особенности и, сопоставив с особенностями других известных технологий, оценить перспективы ОТ.
Кроме оценки перспектив, такой анализ мог бы принести и непосредственную пользу.
1) Привести к более сознательному программированию на Обероне, опираясь на понимание базовых принципов ОТ, а не в рамках упоминавшегося где-то в наших ветках "синтаксического мышления".
2) Научить нас применять ОТ, даже будучи вынужденными пользоваться другими языками программирования.
3) Возможно, мы дозреем и до того, что сами сумеем в отдельных пунктах дорабатывать ОТ. Кто знает? :)

Для себя я определяю ключевой признак ОТ следующим образом:
"Безопасность программирования превыше всего".
Другими словами, язык и среда должны в максимальной степени закрывать все возможности программиста сделать ошибку при написании кода или, по крайней мере, свести к минимуму возможные последствия этой ошибки.
Все остальные "родовые" признаки ОТ я считаю следствием этой главной концепции:
1) Концепция модуля, как "закрытой" от внешних воздействий единицы компиляции;
2) Строгая статическая типизация данных и жесткий контроль согласования типов;
3) Автоматическая сборка мусора и никакой арифметики указателей;
4) Простая грамматика языка и возможность ее полного описания в нотации Бэкуса-Наура;
Собственно благодаря этому я и пришел к ОТ.

Вообще-то очень странно все это выглядит. AVC в своем посте за №1 вполне конкретно сформулировал ключевые для данной ветки вопросы. Много чего мы слышали про ошеломительные Оберон-технологии, как то: про их небывалую красоту, запредельную математическую выверенность и бог весь еще что. Но как только в предельно ясных и простых выражениях попросили наших корифеев сформулировать основные принципы этих самых ОТ, без агитпроповской шелухи("а вот мы..., но вам не покажем!"), как тема заглохла. Уважаемые Руслан Богатырев, info21, Trurl, Сергей Губанов, Владимир Лось и другие бойцы Обероновского направления. Будьте добры, объясните все-таки нам, что такое есть Оберон-технологии, перечислите и объясните по пунктам. Думаю, это интересно многим.

Ответ на »сообщение 3« (zar)
___________________________
Совершенно согласен. Похоже их (специфических технологий) просто нет.

"А можешь ли ты показать нам знак, знамение, чтобы мы поверили, что ты посланница Бога, а не диавола?" (С) Люк Бессон

Предлагаю упражнение: Возьмите описания С++, Явы и Оберона/Ком. Паскаля и попытайтесь найти отличия.

----
Замечание насчет логики: если вам не дают ответа, это не значит, что ответа нет. Не повторяйте ошибки Р.Богатырева.

Ответ на »сообщение 2« (Q. Werty)
___________________________

Для себя я определяю ключевой признак ОТ следующим образом:
"Безопасность программирования превыше всего".
Другими словами, язык и среда должны в максимальной степени закрывать все возможности программиста сделать ошибку при написании кода или, по крайней мере, свести к минимуму возможные последствия этой ошибки.
Все остальные "родовые" признаки ОТ я считаю следствием этой главной концепции:
1) Концепция модуля, как "закрытой" от внешних воздействий единицы компиляции;
2) Строгая статическая типизация данных и жесткий контроль согласования типов;
3) Автоматическая сборка мусора и никакой арифметики указателей;
4) Простая грамматика языка и возможность ее полного описания в нотации Бэкуса-Наура;
Собственно благодаря этому я и пришел к ОТ.


Большое спасибо, Ваш ответ -- хорошее начало для анализа ОТ.
Согласен с Вами, что главная цель ОТ -- надежность.
Но, ИМХО, нам еще только предстоит детальный анализ механизмов ОТ, для чего и создана ветка.
Сам я главными (целевыми) характеристиками ОТ считаю следующие.
1. Надежность. (В чем полностью согласен с Вами.)
2. Гибкость. (В т.ч. -- расширяемость. Но не только; другой пример -- многомерные гибкие массивы.)
3. Эффективность. (ОТ не требует JVM, может эффективно работать по "голому железу", что -- в моем случае -- представляет значительный интерес.)
4. Простота. (Добиться выполнения всех трех предыдущих требований самым простым путем. Эта цель четко обозначена эпиграфом к описанию О-1: "Make it as simple as possible, but not simpler". Первые три пункта показывают, что значит "not simpler", и почему Оберон -- не brainfuck (есть такой дурацкий язык :) ).)
Опять же, повторюсь, это только основные характеристики, цели ОТ.
Нам же, смею надеяться, здесь предстоит именно анализ механизмов.

Языки программирования имеют разные цели.
Целью Си было совмещение низкоуровневого и высокоуроневого программирования (т.е. решение этого противоречия) в одном языке. Отсюда -- адресная арифметика, спецификатор register, инкрементные операторы.
Целью Си++ было сочетание противоречивых требований абстракции и эффективности. Это вполне согласуется с целями Си. Отсюда -- inline, template и т.д.

На мой взгляд, целью виртовских языков было сочетание противоречивых требований надежности, гибкости и эффективности, но приоритет всегда отдавался надежности.
Давайте рассмотрим с этой точки зрения язык Паскаль.
Small и inflexible, по словам Страуструпа. (Впрочем, какой еще оценки можно было ожидать от человека, чья фамилия является олицетворением множественного наследования? :) )
Но нас будет интересовать ответ на вопрос: а почему Паскаль inflexible?
Что, Вирт не мог создать аналога Си?
Да запросто!
При этом надо было пожертвовать только одним -- надежностью.

Вот интересная черта (классического) Паскаля: он не модульный.
Текст паскалевской программы начинается словом program, заканчивается словом end и точкой.
Все остальное -- между этим.
Как будто весь текст программы должен быть написан одним человеком.
Вопрос: почему так?
Предполагаемый ответ: не была еще в то время разработана технология раздельной компиляции, нельзя было обеспечить надежности при использовании нескольких модулей (да и понятия модуля -- в современном смысле -- тогда еще не было).
Как решил эту проблему Си? Да никак! #include, а там -- Бог поможет.
Во многом прогресс вдоль линейки Паскаль -- Модула-2 -- Оберон есть история технологии раздельной компиляции.
Именно она, в конце концов, позволяет оберонщикам аж с 80-х годов наслажаться надежным компонентным программированием (как с динамической загрузкой, так и с проверкой типов!), в то время как весь мир барахтался (да и сейчас еще барахтается) в прежних нерешенных проблемах Си, что получило название "DLL hell".

Другой интересная особенность Паскаля -- включение размерности массива в его тип.
Это еще как критиковали, не стану сейчас пересказывать Кернигана.
Как с эти справлялся Си? Да никак! В нем, можно сказать, нет массивов, тем паче -- контроля выхода за границы массива.
В Модуле-2 появились гибкие массивы, в Обероне -- многомерные гибкие массивы, а в Обероне-2 -- динамические многомерные гибкие массивы.
И все это -- без потери надежности, по мере возможности добавляя гибкость!

В этом разница между Виртом, с одной стороны, и Ритчи и Страуструпом -- с другой.
Один решал проблемы, другие ей просто пренебрегли.
Ну, на то они и молодцы, а Вирт -- старый чудак. :)

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

Ответ на »сообщение 6« (AVC)
___________________________
Господа, похоже сначала надо определить что есть "технология".
По моему, говорить что "главная характеристика технологии это надежность" неверно. Надежность может (именно может, а не должна) быть целью, а технология XYZ - средством достижения цели. Это е относится и к простоте.

Несколько замечаний по ходу дела:
1) целью создания языка Си было не совмещение высокого с низким, а создание удобного инструмента написания операционной системы Unix. Предудущая система авторов (Multics) писалась на PL/1, который был явно неудобным инструментом.
2) технология раздельной компиляции появилась не после Паскаля, а значительно раньше - в Фортране.
3) #include не имеет никакого отношения к раздельной компиляции - это средство обьявления общих констант, общих кусков текста и так далее.
4) ...

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


Господа, похоже сначала надо определить что есть "технология".
По моему, говорить что "главная характеристика технологии это надежность" неверно. Надежность может (именно может, а не должна) быть целью, а технология XYZ - средством достижения цели. Это е относится и к простоте.

Во многом согласен с Вашим замечанием.
Похоже, я недостатно четко разделил цели и средства.
Все же я пытался использовать разные слова (термины) для их разделения.
Для целей я использовал слова: цели, основные (целевые) характеристики.
Для средств я использовал слово "механизмы".
Я согласен, что цели и средства следует различать.
Если будут предложения, как придать терминологии большую точность и выразительность, буду благодарен.


Несколько замечаний по ходу дела:
1) целью создания языка Си было не совмещение высокого с низким, а создание удобного инструмента написания операционной системы Unix. Предудущая система авторов (Multics) писалась на PL/1, который был явно неудобным инструментом.

ИМХО, именно по причине недостаточной низкоуровневости и чрезмерной сложности PL/1.
Или нет?


2) технология раздельной компиляции появилась не после Паскаля, а значительно раньше - в Фортране.

Мне кажется, что в данном частном случае Вы путаете независимую и раздельную компиляцию.
Независимая компиляция существует во многих языках.
Например, в тех же Си и Си++, а также в некоторых реализациях Паскаля.
Но она не обеспечивает должный контроль совместимости типов и целостности программной системы поверх модулей.
Именно таким контролем раздельная компиляция и отличается от независимой.


3) #include не имеет никакого отношения к раздельной компиляции - это средство обьявления общих констант, общих кусков текста и так далее.


#include есть попытка обеспечить целостность программы вручную, переложив эти проблемы на плечи программиста.
Такова позиция Си и во многих других вопросах.
Данный подход еще как-то работал на уровне отдельных приложений, но оказался недостаточно неприспособленным для перехода к компонентному программированию.

#include есть именно следствие независимой компиляции.
Раздельная компиляция не является независимой, т.к. в ней учитываются зависимости компилируемого модуля от его импорта.
Если Вы считаете, что #include не имеет никакого отношения к проблемам независимой/раздельной компиляции, то как Вы объясняете, что в Си он есть, а в Модуле-2 и Обероне его нет?

Ответ на »сообщение 8« (AVC)
___________________________
Обо всем прочем я подумаю завтра, а насчет перехода от PL/1 к Си история, со слов разработчика, была следующей - низкоуровневости в PL/1 хватало и сложность не пугала, но это был "перфокарточный"  язык.

То есть операторы набивались на перфокарты (это такие картонные таблички) негритянками-перфораторщицами (в советских реалиях - девочками-перфораторщицами). На производительности программиста многословие PL/1 и практика использования прописного и строчного регистра не сказывались.

На машине PDP-7, на которой и для которой разрабатывался Unix, в качестве устройства ввода и вывода использовались телетайпы ASR-33 за которыми сидели сами программисты. Эти программисты экономили каждое нажатие клавиш и это, было основным критерием пригодности языка. Вначале был выбран BCPL, язык предназначенный для написания компиляторов (http://en.wikipedia.org/wiki/BCPL), затем его упростили, сократили, ввели типы, удалили верхний регистр ключевых слов  и переименовали в B , а затем еще изменили и переименовали в C.

Если это анекдот, то интересный. Одним из спидетельств в подтверждения вышесказанного является то, что команда "Unmount" в Unix названа umount - букву но сэкономили.

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

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

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

Итак, есть мир Оберонов. Это языки программирования (ЯП), соответствующие им системы программирования (СП), операционные системы (ОС), а также конкретные технологические приемы/решения, которые сконцентрировались в мире Оберонов либо в силу "запросов" самого проекта Oberon (Project Oberon), либо как побочный продукт.

Повторю ту мысль, которую высказывал в соседней ветке по Оберон-языкам: Оберон-технологии -- это не то, что впервые появилось именно в мире Оберонов. Это то, что там было сконцентрировано, раскрыто, детально изучено и представлено остальному миру.

Что, на мой взгляд, можно включать в понятие Оберон-технологии? Одно из значений слова "технология" в русском языке -- совокупность приемов, применяемых в каком-либо деле, мастерстве, искусстве. Это переложение научных основ на практику. Поэтому предлагаю включать в обсуждение данной тематики те все составные части мира Оберонов (ЯП, СП, ОС, проекты, приемы/решения), которые подпадают под прикладной аспект. Границу провести нелегко, но попробуем.

Если говорить о языках Оберон-семейства (Оберон, Оберон-2, Компонентный Паскаль, Active Oberon, Zonnon), то стоит затронуть те их аспекты, которые могут быть отчуждаемы (применены в других языках). Поскольку все остальное -- предмет изучения соседней ветки по Оберон-языкам.

Если затрагивать системы программирования, то основное внимание стоит уделить двум наиболее ярким -- ETH Oberon и BlackBox. Обе они технологически заметно выделяются на фоне привычных СП тем, что являются расширяемым инструментарием, превращающимся в целевую систему. Это ключевой момент.

В отношении ОС -- это, пожалуй, основное поле Оберон-технологий, где они формировались и оттачивались. Тут безусловно приоритет надо отдавать Oberon System. Что касается Bluebottle -- это отдельный разговор, это новое поколение Оберон-решений, к нему надо идти через осознание оригинальной системы Oberon.

С чего начинать? Есть две основополагающие книги по Оберон-технологиям: Project Oberon — The Design of an Operating System and Compiler (2005) и Programming in Oberon. Steps Beyond Pascal and Modula (1992). Оберон-технологии в большом и Оберон-технологии в малом.

Далее, основные достижения Оберон-технологий сконцентрированы в диссертациях ETH. Наиболее важные, с моей точки зрения, выложены на http://www.oberon2005.ru/oberon.html (раздел "Диссертации учеников и последователей Вирта").

Если в них проводить градацию, то выстроил бы (в порядке убывания приоритета) так:

1. M.Franz. Code-Generation On-the-Fly: A Key to Portable Software (1994)
2. R.Crelier. Separate Compilation and Module Extension (1994)
3. J.Marais. Design and Implementation of a Component Architecture for Oberon (1996)
4. R.Sommerer. Integration of Online Documents (1996)
5. J.Templ. Metaprogramming in Oberon (1994)

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