Ответ на »сообщение 15« (Руслан Богатырев)
___________________________
Представляете, может ведь, негодяй. Для истинных гурманов от программирования -- не все и не в достаточном количестве, но "морозить" может.

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

1) помимо XDS это могут делать все компиляторы с Оберона. Есть такая команда Open.Ascii.
2) проблем в реализации такого проекта может быть и нет, но проекта тоже нет (ни одного)

На роли гуру надо быть тщательнее.

Ответ на »сообщение 14« (Jack Of Shadows)
___________________________

Я думаю правильнее будет искать то что не привязано к конкретному языку.

Логика потрясающая! Ищите, господа, то, что не привязано к конкретному языку. Вот призыв уважаемого Jack of Shadows. Я поясняю -- вот Оберон-технологии, они собраны в одном месте, не привязаны к конкретному языку. Бери и пользуйся. Мне в ответ -- это не Оберон-технологии, потому что не привязаны. Ну, так за чем дело стало, возьмем атласную ленточку и привяжем.

Остается только попросить уважаемого Jack of Shadows, может быть, он сможет привести хоть один пример технологии из сферы того же функционального программирования, которая реализуется только (только и исключительно!) на одном конкретном языке и ни на каком другом на свете.

Я тоже могу привести много работ где в качестве языка реализации используется лисп.

Ну такого от Вас не ожидал. В работе Франца Оберон является не столько языком реализации, сколько объектом исследований. Придется привести и в этой ветке слова Жванецкого. Быть может, немного станет понятней:
Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма. Давайте сталкивать философов, не читая их работ. Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто ел их, до хрипоты, до драки, воспринимая вкус еды на слух, цвет на зуб, вонь на глаз, представляя себе фильм по названию,живопись по фамилии, страну по 'Клубу кинопутешествий', остроту мнений по хрестоматии.

Прекрасный механизм! Уж мне ли не знать! :))

Правда, тогда расскажите, в чем он конкретно заключается в языке Оберон? Своими словами, как Вы понимаете. Глядишь, поймем, насколько он к языку привязан и привязан ли вообще.

А вот скажите Руслан, если уж оберон ОС поддерживат работу в документной парадигме, позволяет он сохранить состояние системы со всеми заргуженными модулями, инициализированными переменными, открытыми окнами итд итп, сохранить с целью последующего запуска.

Представляете, может ведь, негодяй. Для истинных гурманов от программирования -- не все и не в достаточном количестве, но "морозить" может.

Благодаря этой вот документной ориентированности ОС оберон, практически нет ни одного распределенного интернет open source проекта на обероне.

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

Уж на что я тут изо всех сил рекламирую лисп, но и то не рискнул упомнить о такой вот фиче как о преимуществе :))

Верю, что Вы очень любите Лисп. Но силюсь понять, причем здесь данный форум? Вот если Вы сможете разобрать для примера любую из Оберон-технологий и привести параллель с Лиспом -- честь Вам и хвала. Будет очень полезно.

Ответ на »сообщение 13« (Руслан Богатырев)
___________________________
деревья Франца и его семантический словарь работают не только для Оберона,
О том и речь. Каша вкусна, речи нет. Но при чем тут топор, ээ оберон ?
Может отделим мух от котлет ? Я тоже могу привести много работ где в качестве языка реализации используется лисп. Но называть функциональные технологии или работы по логическому прогаммированию, или искусственному интеллекту - лисп-технологиями, чтобы заодно с востребованным материалом протолкнуть и любимый язык, это уже не очень хорошо (честно ? ) выглядит.

Хотите отдать должное первооткрывателям ? Благородное намерение. Ну что ж, встали, повернулись, отдали поклон команде Вирта...и все в общем то.

Родовой (generic) протокол передачи сообщений между объектами.
Прекрасный механизм! Уж мне ли не знать! :)) defgeneric в лиспе не зря так назван. Очень рад что гораздо более мощный механизм декларации и взаимодействия обьектов нежели обычный message-passing через столько то лет проник наконец из лиспа в хоть один императивный язык. Но опять же, где оберон-технологии ?

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

Опять же DrScheme.org и можете насладаться средой с такой же документной ориентированностью, с встроенными картинками, графиками и спредшитами прямо в вашем коде.
Уж на что я тут изо всех сил рекламирую лисп, но и то не рискнул упомнить о такой вот фиче как о преимуществе :))

4. В системе Oberon можно запустить на выполнение любую часть текста, которая на лету разбирается, отождествляется с командой ОС


Ах!! Радость работы в REPL! Нажимаешь Ctrl-Alt-X и выделенная часть текста.. ну вы поняли :))
Лисперы и смолтокеры наслаждаются такой возможностью вот уже несколько десятилетий :))

Впрочем это же касается любого языка который работает в своей ОС.

А вот скажите Руслан, если уж оберон ОС поддерживат работу в документной парадигме, позволяет он сохранить состояние системы со всеми заргуженными модулями, инициализированными переменными, открытыми окнами итд итп, сохранить с целью последующего запуска.
Как например в лисп - save-image, load-image.
Т.е. снапшот текущего состояния системы можно сохранить ?

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

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

Если же господа не так уж и сильно зациклены на паскале и его потомках...то перед вами открыт ВЕСЬ МИР. Огромное количество возможностей, технологий, стилей, чего угодно. Зацикливаться на оберон-технологиях, java-технологиях, лисп-технологиях, Microsoft-технологиях - это значит сильно ограничивать себя.
Я думаю правильнее будет искать то что не привязано к конкретному языку.

Ответ на »сообщение 11« (Jack Of Shadows)
___________________________

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

С этим не могу согласиться. Оберон-технологии отчуждаемы от Оберонов и это хорошо. Считать их безусловной собственностью мира Оберонов -- это и есть агитация и пропаганда.

Давайте по порядку. Из того, что сразу приходит в голову.

1. Работа Франца по динамической кодогенерации. Если Вы читали его диссертацию, то наверняка обратили внимание на важное утверждение -- деревья Франца и его семантический словарь работают не только для Оберона, а для разных императивных языков (как минимум). Чем это плохо? Есть по факту в классическом Обероне. Хотя и в мир Java перенесены группой того же Франца на уровне гарантии безопасности мобильного кода.

2. Родовой (generic) протокол передачи сообщений между объектами. Это здесь уже тщательно обсасывали. Опирается на конкретный прием в языке Оберон, описанный, в частности, в Programming in Oberon (2004) Никлауса Вирта. Полезная вещь. Бери и пользуйся. Но в Обероне -- самое оно, донельзя просто. На нем построена система Oberon.

3. Документ-ориентированная система программирования со встроенными аплетами. В ETH Oberon любой документ (включая исходные тексты) может содержать визуальные объекты, элементарно интегрируемые в текст. Это аплеты со своим поведением.

4. В системе Oberon можно запустить на выполнение любую часть текста, которая на лету разбирается, отождествляется с командой ОС (процедурой без параметров в соответствующем загруженном модуле) и может принимать на вход параметры даже в графическом виде (то, что выделил пользователь перед активизацией). Сам текст может быть хоть в заголовке окна. Это предвестник т.н. смарт-тегов из Microsoft Office. Подробнее см. http://old.osp.ru/pcworld/2002/07/052_1.htm

Краткий ликбез по Оберон-технологиям можно найти, напр., в работе Гуткнехта "Оберон: перспективы эволюции" (1994) http://www.oberon2005.ru/paper/obe_evol.pdf

Но там какой-никакой агитпроп. Так что делайте, господа-товарищи, поправку на ветер.

В отношении Оберон-технологий важно иметь следующее: Вирт и его команда попали на самую волну новаций и исследований, темп которым задавал Xerox PARC, при этом они шли по пути творческой переработки и максимального упрощения сложных и подчас запутанных решений американцев. В чем заметно преуспели. У Вирта очень хорошо была поставлена работа с кадрами. В результате удалось взрастить из талантливой молодежи довольно сильных исследователей. Очень серьезно мониторились параллельные конкурентные исследования. Все это вместе взятое выкристаллизовывалось в то, что теперь мы называем школой Вирта, Оберон-технологиям и Оберон-решениями.

Я намеренно ухожу от скользкой темы приоритетов. Если это так важно, мы можем к этой теме еще не раз вернуться. Но давайте сначала уделим внимание сути, а не тому, кто и когда первым пересек финишную черту.

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

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

Согласен с Вами, что главная цель ОТ -- надежность.

А я не могу согласиться. Главная цель, на мой взгляд, -- простота (если мы имеем в виду, конечно, подход Вирта/Гуткнехта в проекте Oberon). Постараюсь аргументировать свою позицию в этой и соседней ветке по Оберон-языкам.

В языке Оберон отсутствует немало средств обеспечения надежности (явное выделение трассируемой и нетрассируемой памяти, SAFE/UNSAFE-маркировка модулей, полноценная обработка исключений). Все то же отсутствует и в других Оберон-языках. При этом с точки зрения надежности Компонентный Паскаль выглядит более выигрышно, нежели классический Оберон.

4. Простота. (Добиться выполнения всех трех предыдущих требований самым простым путем. Эта цель четко обозначена эпиграфом к описанию О-1: "Make it as simple as possible, but not simpler".

Интересно, что этот эпиграф Эйнштейна я где-то уже видел. Не только в виртовском каноническом описании Оберона. Ах, да: он приведен Батлером Лэмпсоном (Butler Lampson) в его работе "Hints for Computer System Design" (July 1983). Тем самым Лэмпсоном, который, как и Вирт, является лауреатом престижной премии Тьюринга (1992). Который c момента основания (1970) работал долгие годы в Xerox PARC над проектом Xerox Alto, над разработкой Mesa и Cedar, затем ушел в DEC SRC, где работал над Modula-2+, затем Modula-3. А сейчас... Угадали, в Microsoft Research -- http://research.microsoft.com/Lampson/Systems.html

Тень отца Гамлета...

Ответ на »сообщение 10« (Руслан Богатырев)
___________________________
а также конкретные технологические приемы/решения, которые сконцентрировались в мире Оберонов либо в силу "запросов" самого проекта Oberon (Project Oberon), либо как побочный продукт.

Руслан. Если эти технологические приемы/решения не привязанны жестко к Оберону, то говорить об "оберон-технологиях" это уже выражаясь вашими словами - агитпроп.
В ветке профункциональное программирование мы уже говорили об этом. Основы функционального программировнаия существуют в любом императивном языке. Но именно отсутствие\присутствие конкретных механизмов В ЯЗЫКЕ делают эти языки императивными или функциональными. Т.е. речь идет о конкретных вещах а не о чем то эфемерном.

Если вы можете представить такие механизмы, которые существуют в обероне в противовес скажем java и сишарп, которые позволяют использовать оберон-технологии (черт возьми что это такое ?) только на обероне - давайте о них говорить! Давайте их показывать. Конкретными примерами, кодом. Пусть присутствующие убедятся - да. такое можно сделать ТОЛЬКО на обероне. Да это и есть оберон-технологии.
Если же таких механизмов нет, то рано или поздно люди раскусят что им варят кашу из топора. :))

Ответ на »сообщение 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)

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

Ответ на »сообщение 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 - букву но сэкономили.

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


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

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


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

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


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

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


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


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

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

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

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