По-моему, мы уклоняемся от темы.
Эта ветка посвящена ОТ в целом (существенным свойствам, общим для всех оберонов).

Сравнение Оберона и КП разумно проводить в ветке о языках Оберон-семейства и их эволюции.
Там имеет смысл анализировать расхождения между языками и причины таких расхождений.
ИМХО, это естественный процесс, подобный образованию видов в живой природе. :)

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

1. Раздельная компиляция.
Раздельная компиляция существует не только в виртовских языках, о чем напомнил Руслан Богатырев.
Но (ИМХО) именно в Обероне раздельная компиляция стала основой новой технологии.
Я имею в виду (дополнительно к межмодульному контролю типов):
- динамическую загрузку и линковку (статическая линковка не требуется);
- fingerprints, позволяющие в принципе не только контролированть целостность динамической системы модулей при загрузке, но и расширять (а в отдельных случаях -- и сужать!) интерфейс (!) модуля без перекомпиляции клиентов.
Мне пока неизвестны о существовании подобных "фич" до Оберона.
Если кому-нибудь такое известно, пусть меня поправит. Я буду только благодарен.
Как мне кажется, именно развитие раздельной компиляции сделало Оберон -- технологией, а не просто еще одной операционной системой или семейством языков.
На раздельную компиляцию опираются многие другие особенности ОТ.
Кроме того, предполагаю, что slim binaries -- побочная ветвь раздельной компиляции.

2. Родовые интерфейсы (программная шина).
Мне больше нравится выражение "software bus" (программная шина), на которое я наткнулся при чтении ETH Oberon White Paper.
Как известно, программная шина позволяет добавлять новые сообщения в систему, не требуя перекомпиляции клиентских модулей.
Поэтому, ИМХО, она является дополнением к раздельной компиляции.
В каком-то смысле, аналогом программной шины являются системы рассылки сообщений в Windows и Mac OS (к сожалению, насчет второго сужу с чужих слов; если ошибаюсь, пожалуйста, поправьте меня).
Но разница между рассылкой сообщений в Windows и Oberon в чем-то подобна разнице между независимой и раздельной компиляцией.
Только обероновская версия является типобезопасной (type-safe).
И здесь большое значение имеет реализация расширения типа в Обероне.
Каждый тип записи в Обероне имеет свой уровень расширения.
Дескриптор типа содержит небольшой массив указателей на дескрипторы базовых типов.
Благодаря этой маленькой хитрости, динамическое определение типа (v IS T) в Обероне требует всего одного сравнения.
Согласитесь, для динамического определения типа -- это очень эффективно.
Т.е. в языке Обероне мы имеем надежный (type-safe) и эффективный механизм для поддержки технологии программной шины.
Здесь язык смыкается с технологией.
Пока не могу сказать насчет других языков, я слишком закопался в Си и ассемблере, одичал совсем в своем Зеленограде. :)
Буду благодарен за информацию по этому поводу.

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

Ответ на »сообщение 52« (Руслан Богатырев)
___________________________
В книжке The Oberon Companion. A Guide to Using and Programming Oberon System 3 с сайта www.oberon2005.ru на странице 65 речь идет о гаджете Button то есть абсолютно не о том.

Предвосхищая ваш ответ, что у меня не та книжка сообщаю, что печатное издание маркировано как:

The Oberon Companion: A Guide to Using and Programming. Oberon System 3", Andre Fischer, Hannes Marais, vdf Verlag der. Fachhochschulen, Zurich, 1997, ISBN 3-7281-2493-1.

Похоже, что ссылка взята с потолка.

Я не предупреждаю, а советую, формулируя что-то тщательно проверяйте файты.

Кроме того, вся цитируемая книжка, за исключением вводной главы, посвящена Gadgets, а я уже говорил, что Gadgets является дополнительным, необязательным пакетом к System 3.

Ответ на »сообщение 53« (Руслан Богатырев)
___________________________

Это же секрет Полишинеля. Вот навскидку три ссылки с открытой информацией, по источникам можете посмотреть глубже сами:
тут я несогласен тк прямых слов что это делается ДЛЯ info21 only(ради) там я ненашел так что "перенос под Linux для конкретных исследовательских работ info21" - неправда

Оказывается, был нужен в роли "свадебного генерала", человека, который пробивал бы в "Мире ПК" BlackBox. Никакого обсуждения даже в узком кругу участников проекта. Никаких советов. Плевать на них хотели. С высокой колокольни. Полгода молчал. Терпеливо ждал, вдруг все же за ум возьмутся. Куда там.
если это так, то действительно печально

Ну а насчет "бурной" поддержки того же языка Оберон со стороны info21 -- посмотрите некоторые обсуждения на форуме blackbox.metasystems.ru. Там кое-какие следы найдете. Вот одна из точек обсуждения: http://blackbox.metasystems.ru/forum/viewtopic.php?t=50&postdays=0&postorder=asc&start=0

а бурной поддержки быть и не должно
люди занимаются КП пусть занимаются
найдите единомышленников и разрабатывайте Оберон (он не менее достоин этого)
главно вражду не устаивать
если не ошибаюсь одной из причин нераспространенности Оберона вы называли расщепление сил на разные ветки os3 os4 оберон2 кп активный оберон и тд еще внутри eth, может не усугублять картину разжиганием войн
все же часто Вы упоминаете info21 как бы всколзь но очерняя (еще из векти которую закрыли)(точнее раньше такого не было)
прям черный пиар...

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

>>перенос под Linux для конкретных исследовательских работ info21.
обосновать это высказывание можете?(подтвердить чем нить)
а то многим винда не нравится а перевод под линукс специально для info21
смешно так то

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

1. http://www.progz.ru/forum/viewtopic.php?t=1748&sid=f6b592043b77cec6400904486a15a4cd

ОМ должны зарабатывать деньги, а бизнеса, связанного с Линуксом, у них нет.

Впрочем, они интересуются grid-технологиями, и под это дело (например, под какой-нибудь проект в CERNе) может появиться некая версия ББ для Линукса.

Stay tuned

2. http://blackbox.metasystems.ru/forum/viewtopic.php?t=58&highlight=linux

Идет работа. Медленно, но идет. Сначала делается без-ГУЙный вариант для счета на кластерах (строго в соответствии с очередью конкретных задач, без фантазий от балды). Потом остальное. Впрочем, ГУЙ в стадии альфы получен от Oberon microsystems летом.

3. blackbox.metasystems.ru/download/books/ogu-fizmat-04-2006.pdf

Активно используется швейцарскими и российскими ядерными физиками (CERN и ИЯФ РАН, [5]). Существуют версии для Windows и MacOS. В настоящее время в ИЯФ РАН разрабатывается версия под Linux, в том числе для распределенных
вычислений на кластерах.

___________________________

и по поводу прижатия других языков информатикой 21
http://www.inr.ac.ru/~info21/info/koordinatory.htm
один из координаторов занимается eth oberon и никто его не убрал
так что это домыслы об очень агрессивном подавлении др ответвлений оберона
и уж оличных коварных замыслах info21

Не убирают -- угодных, а убирают -- неугодных. Раз за Вашего координатора. Рад, что терпят ETH Oberon, который потом называют музейным экспонатом, а Вирта -- человеком, который не может отличить Оберон от КП.

Не скажу за Вашего координатора, скажу за себя. Что касается проекта "Информатика-21", то меня г-н info21 пригласил туда в конце 2004 г. в качестве консультанта. Я-то наивный думал, что принесу какую-то пользу проекту. Оказывается, был нужен в роли "свадебного генерала", человека, который пробивал бы в "Мире ПК" BlackBox. Никакого обсуждения даже в узком кругу участников проекта. Никаких советов. Плевать на них хотели. С высокой колокольни. Полгода молчал. Терпеливо ждал, вдруг все же за ум возьмутся. Куда там.

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

Ну а насчет "бурной" поддержки того же языка Оберон со стороны info21 -- посмотрите некоторые обсуждения на форуме blackbox.metasystems.ru. Там кое-какие следы найдете. Вот одна из точек обсуждения: http://blackbox.metasystems.ru/forum/viewtopic.php?t=50&postdays=0&postorder=asc&start=0

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

См. The Oberon Companion. A Guide to Using and Programming Oberon System 3 (1998), стр. 65.

Раз ниже упоминались "понятия', то "за базар надо отвечать'

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

Ответ на »сообщение 46« (Руслан Богатырев)
___________________________
Все таки хотелось бы услышать о сохранении состояния системы Oberon System 3 между перезагрузками.
Варианты ответа:
1) приводится конкрентая команда или ссылка на документацию
2) "я не знаю как"
3) "сказал, о отвечать не хочу"

Раз ниже упоминались "понятия', то "за базар надо отвечать'

Кстати, гаджеты упоминать не стоит - Gadgets является дополнительным к системе пакетом и система прекрасно работает без него.

Ответ на »сообщение 49« (Руслан Богатырев)
___________________________


перенос под Linux для конкретных исследовательских работ info21.

обосновать это высказывание можете?(подтвердить чем нить)
а то многим винда не нравится а перевод под линукс специально для info21
смешно так то

и по поводу прижатия других языков информатикой 21
http://www.inr.ac.ru/~info21/info/koordinatory.htm
один из координаторов занимается eth oberon и никто его не убрал
так что это домыслы об очень агрессивном подавлении др ответвлений оберона
и уж оличных коварных замыслах info21

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

Что значит в фаворе... Может дело не в фаворе ? Может в консерватории че подправить надо ? :))

Это значит, что он не пользуется достаточным вниманием/интересом у тех, кто участвует в OpenSource-движении. Те, кто регистрируют проекты на том же SF, имеют на это определенную мотивацию. На SF только один яркий активный Оберон-проект  -- OO2C, http://ooc.sourceforge.net/

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

Удивляться отсутствию развиваемых сегодня OpenSource-проектов не приходится.

Инструментарий. ETH Oberon в силу своей замкнутости сам по себе не стал стимулом для развития OpenSource-проектов. КП/BlackBox лишь 2 года назад вышел из чисто коммерческого обращения. XDS -- около года.

Немодность Оберона. Заниматься новыми языками (особенно скриптовыми) модно. Даже если о языке слышали единицы. А заниматься "старьем" -- зачем? Ради собственного удовольствия люди могут программировать потихоньку дома, а лезть наружу с проектами -- определенно нужен стимул.

Катализаторы развития. Кто является основным двигателем OpenSource-движения, если исключить "конверсию" (скрытый демпинг и "слив" отработанных технологий коммерческими компаниями)? Студенты и фрилансеры.

Что с Обероном в этих "потребительских" группах? Туго. На Западе совсем. А у нас... Об "обширном" составе участников проекта "Информатика-21", который в сентябре отметит свое 5-летие, можно получить исчерпывающую информацию здесь http://www.inr.ac.ru/~info21/info/uqastniki.htm

Можете обратить внимание, какое кол-во вузов и ИТ-факультетов представлено (и с какого времени).

В России в силу весьма своеобразной политики проекта "Информатика-21" все сконцентрировано вокруг BlackBox. Сначала все силы были брошены на его локализацию (включая документацию), потом на перенос под Linux для конкретных исследовательских работ info21. При этом основной целью упомянутого проекта по факту являются школы, которые очевидно ничего не могут дать OpenSource-движению, а могут только взять.

Вместо кооперации усилий по продвижению Оберона -- конфронтация. Открытая. Сплошная агитация и пропаганда. Причем в весьма агрессивной форме. Зачем? Риторический вопрос.

Вывод, который я для себя сделал: надо мне пересматривать свою позицию невмешательства/соглашательства. Что собственно и делаю. Так что насчет консерватории -- это верное замечание. Будем подправлять.

Кстати вполне может быть что оберонщики хостятся где то еще.
Так многие делают.
Основной репозиторий для лисперов это не sf а common-lisp.net
У scheme-ров тоже есть свои сайты где они хостят.

Так что может SF и не дает обьективную картину по оберонам.
Может подскажете, где их искать ? эти open source активные проекты на обероне ?

Ответ на »сообщение 46« (Руслан Богатырев)
___________________________
почему Оберон не в "фаворе" -- эту тему неоднократно комментировал и раскрывал.

Что значит в фаворе Руслан ? Вот такой экзотический язык как Lua, явно пользуется меньшим количество народа чем обероны. Значит он в меньшей фаворе чем оберон, правильно ?
Смотрим на SF - там 123 проекта на Lua !! Причем с активностью в 95% - 97%

Scala - вообще никому не известный язык. На SF - 6 проектов (активных)
Boo - голову даю на отсечение, вы даже не слышали о таком языке. 8 проектов на SF !!

Про лисп и scheme даже упоминать не стоит. Более 600 проектов !!

Может дело не в фаворе ? Может в консерватории че подправить надо ? :))

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

Руслан, упоминание Native Oberon как распределенного проекта (проекта над которым работает распределенная группа программистов, которые географически удалены друг от друга) по моему ошибка.

Я не утверждал, что Native Oberon -- распределенный open source project. Если Вы помните, в ответ на Вашу реплику (»сообщение 14«) я ответил, что "нет никаких проблем в реализации такого проекта", поскольку XDS работает на основе исходников в текстовом представлении (»сообщение 15«). После чего появилось утверждение в безапелляционной форме от г-на 1 (»сообщение 16«) -- "проблем в реализации такого проекта может быть и нет, но проекта тоже нет (ни одного)". Я дал ссылку на Native Oberon в SourceForge и спросил -- а какой статус носит этот проект (»сообщение 17«). На что услышал -- "это не проект" (»сообщение 26«). Моя попытка уточнить критерии open source project в понимании все того же г-на и то, почему вдруг Native Oberon будучи "не проектом" оказался в SF вызвала буру негодования г-на 1 с приведением доказательств мертвости проекта.

Обратите внимание, как происходит подмена понятий: Native Oberon (как, кстати и практически все работы по проекту Oberon и его последующему развитию) являются не просто OpenSource-проектами, но и проектами с открытой документацией. Это прекрасно известно любому, кто мало-мальски изучал мир Оберонов. Был проект или сейчас ведется -- эта тема вообще не обсуждалась. Таким образом, проект Native Oberon был назван даже не просто мертвым проектом (имелось видимо в виду то, что он уже не развивается), но вообще не проектом. Думаю, тут даже нечего комментировать. Точно также можно считать, что и проект Oberon -- это тоже не проект. И вообще непонятно, что в этой ветке обсуждается. Приехали.

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

Может быть в некоторых случаях неудобство а в некоторых невозможность работы с CVS играет не главную роль в этом.

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

По поводу приоритетов, заимствований и пр.
Кто-нибудь обращал внимание на эту цитату?


Good composers don’t imitate, they steal.
Igor Stravinsky


www.zonnon.ethz.ch/archive/The_Concepts_of_Zonnon_6_y041123.pdf

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

Руслан, упоминание Native Oberon как распределенного проекта (проекта над которым работает распределенная группа программистов, которые географически удалены друг от друга) по моему ошибка.
Да проект зарегестрирован на SF. Но над ним никто не работает и никогда не работал на SF.
Более того я поискал на SF. Там всего 4 проекта на обероне, все мертвые, т.е. не развивающиеся.
Что лишь подтверждает что на обероне ПРАКТИЧЕСКИ не пишется распределенных проектов.
Может быть в некоторых случаях неудобство а в некоторых невозможность работы с CVS играет не главную роль в этом. Спорить не буду. Может оберонщики такой странный народ, который предпочитает работать в одиночку.
Это уж вам решать. :))

Ответ на »сообщение 41« (Руслан Богатырев)
___________________________
Еще раз пожалуйста, как Вы сохраните состояние системы Oberon System 3 между сеансами (какой командой)?

Какие могут быть внешние средства контроля версий в ETH Oberon, если ETH Oberon - stand-alone, то есть по отношению к ней нет внешней системы?

Чем плохи перечисленные мной имеющиеся в ETH Oberon средства контроля версий?

Т, что Вы повторили мои слова Blackbox и других компиляторах уже прогресс.

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

Не надо своими словами излагать слова собеседника, особенно когда именно они и подвегаются критике. В сообщении »сообщение 15« в отношении возможности сохранения состояний в системе Oberon написано буквально следующее:
Для истинных гурманов от программирования -- не все и не в достаточном количестве, но "морозить" может.

Поясняю: "не все", означает буквально "сохранить не все состояние системы со всеми загруженными модулями, инициализированными переменными, открытыми окнами и т.д. и т.п., с целью последующего запуска".

Что позволяет сохранять: persistent-компоненты (гаджеты, команда Store), состояние системы Oberon между сеансами (в Oberon System 3).

Далее, ни ETH Oberon, ни BlackBox, насколько мне известно (и по моему мнению), в виду использования системой программирования исходных текстов в бинарном формате (вне зависимости от наличия механизма загрузки-выгрузки исходных текстов в текстовый файл) не имеют возможности использовать внешние известные (а не собственные) средства контроля версий. Средства, применимые для других систем программирования, средства, для которых работа с текстовым представлением -- основное требование.

Для тех систем программирования Оберонов, которые используют для работы в среде текстовое представление исходников (в частности, это касается XDS и Pow!), такой проблемы нет.

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

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

Важное замечание, на этот аспект особое внимание обращал Вирт в статье "From Modula to Oberon". Но, на мой взгляд, это тема другой ветки. Это не Оберон-технология, а средство языка программирования. Хотя границу, конечно, проводить непросто.

Ответ на »сообщение 32« (Alexey Veselovsky)
___________________________
Речь шла о разнице между фактом и предположением. Когда пишется "Оберон системы ...", а на самом деле этого нет, то подобный пост естественно вызывает желание восстановить истину. Когда же пишется "по моему мнению "Оберон системы ..ю" то, зная что это не так, просто пожимаешь плечами и считая это личной реальностью автора.

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

Ну, стандарт Паскаля полноценным не назовешь.
Стандарт Модулы-2, по Вашей оценке, запутан и злоупотребляет формальной нотацией. А стандарта Оберона нет.

В принципе в оценке стандартов виртовских языков готов согласиться. Но есть ли международный стандарт язка Delphi, языка Java? Или они ликвидируют оный недостаток своей "массой"?

Ответ на »сообщение 30« (1)
___________________________
Извините, это был ответ на #28

Ответ на »сообщение 34« (Руслан Богатырев)
___________________________

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

Вы так думаете? Есть ISO Pascal, есть ISO Modula-2. В чем беда?


Ну, стандарт Паскаля полноценным не назовешь.
Стандарт Модулы-2, по Вашей оценке, запутан и злоупотребляет формальной нотацией.
А стандарта Оберона нет.

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

Мне также кажется, что некоторые особенности языка Оберон иногда неправильно понимаются. (Это, само собой, ИМХО.)
Например, расширение типа (type extension) иногда понимается исключительно как минималистский вариант наследования.
Но кроме поддержки механизма наследования, расширение типа позволяет "замкнуть" систему типов, выбросив из языка небезопасные вариантные записи.
Во многих же других языках есть и наследование, и вариантные записи.

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

Вы недавно утверждали, что Модулу-2 погубил именно стандарт.
Мне эта мысль непонятна.

Причины, на мой взгляд, три:

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

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

Вы так думаете? Есть ISO Pascal, есть ISO Modula-2. В чем беда?

Ответ на »сообщение 25« (Руслан Богатырев)
___________________________


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

Если что-то вызывает споры, вопрос не до конца ясен (по крайней мере, мне).
Поэтому, наверное, хорошо, что мы затронули вопрос простота/надежность.

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

Что касается контроля SAFE/UNSAFE, то пока не могу сказать, что он добавляет в плане надежности к средствам Оберона.
По-моему, Алексей Веселовский прав, когда говорит, что надежность должна достигаться через запрет импорта SYSTEM для несистемных модулей.

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

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

Ответ на »сообщение 29« (Руслан Богатырев)
___________________________
Есть очень простой и общепризнанный механизм - всемто того, чтобы отвечать "Оберон-системы могут сохранять состояние между перезагрузками", следует писать "по моему мнению Оберон-системы (и далее по тексту)". При этом у читающего не возникает ошибочного мнения что "Оберон-системы (и далее по тексту)", пост действительно воспринимается как часное мнение и, в случае неверности, легко и безболезненно опровергается.
По моему мнению писать в начале каждого придложения/утверждения словосочетание "по моему мнению" крайней не удобно. По моему мнению очевидно что каждый собеседник высказывает тут, на форуме именно свое мнение. По моему мнению, читать текст где постоянно встречается словосочетание "по моему мнению" также неудобно как и писать такой текст. По моему мнению, ошибочное мнение может возникнуть только у человека с недостаточно критичным складом ума (это по моему мнению, не стоит это воспринимать как истину в последней инстанции). По моему мнению, всвязи со всем вышеперечисленным следует писать нормально, без лишних "по моему мнению" аббревиатур типа "IMHO/IMO" и т.п. По крайней мере, по моему мнению, мне так кажется.

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

Ответ на »сообщение 24« (Сергей Перовский)
___________________________
Резюмируя:

1) примеров Оберон-ОС или их частей могущих сохранять свое состояние не приведено, то есть их нет.
2) в исходном вопросе речь шла о возможности Оберон-компиляторов работать с текстовыми файлами в форматах хост-систем. Отрицающих примеров приведено не было, вместо этого вопрос был подменен вопросом о возможности использования средств контроля версий в ETH Oberon и Blackbox. Для ETH Oberon существует средство контроля версий ObeDAv/WebDAV (и для Bluebottle тоже), см. также CvsClient. Для BlackBox такого средства нет (и это одно из слабых мест BlackBox), для всех автономных Оберон-компиляторов можно использовать штатные для данных хост-систем средства контроля версий.
3) о упомянутом проекте. "Понятиями" я не делюсь, но есть различие между действительно проектом, по которому идет работа, переписка, общение и т.п. и проектом, который зарегистрирован три года назад и брошен. по этому поводу цитирую:
> Around three years ago, Pieter Muller has put up a
> sourceforge project for Native Oberon.

Is Native Oberon that dead now?

Sourceforge is the archive or 'graveyard' of abandoned F/OSS
projects, more than anything else.

Stuff most often goes there when no one has an interest in
working on it any longer.

Bill


Таким образом все три Ваши исходные утверждения оказались неподтвержденными.

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

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

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

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

Вас никто не старается уколоть, но чтобы Ваше сообщение # 15 могло быть признано информативным

Боюсь, я вряд ли могу соответствовать столь высоким Вашим требованиям. Пишу, по всей видимости, абсолютно неинформативные вещи. Не обессудьте, видимо, с информативностью у меня проблемы.

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

Вы сделаете огромное дело, если сможете объяснить, каким образом можно использовать известные средства контроля версий с ETH Oberon или BlackBox. Это и будет конкретным примером.

Это не проект - он стартован 2003-02-26 13:22 и смысл его в выкладке ETH Oberon 2.3.6 на sourceforge и в изменении формата хранения архивов с Arc на Zip. Никакой работы и никаких целей у этого проекта нет.

Ну конечно, в ведущем в мире репозитарии OpenSource-проектов SourceForge.net регистрируются не проекты, а непонятно что. И куда их администрация смотрит, Интересно, что у Вас, оказывается, свои понятия того, что такое open source project. Поделитесь с общественностью этими понятиями. Быть может, и мы начнем по ним жить.

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

Если разговор зашел о документ-ориентированной системе, значит есть некоторая теория. Можете процетировать из нее определение документа? 

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

Ответ на »сообщение 17« (Руслан Богатырев)
___________________________
Вас никто не старается уколоть, но чтобы Ваше сообщение # 15 могло быть признано информативным пожалуйста укажите любую Оберон-Ос позволяющую сохранить состояние системы (так ставился вопрос). Или, если это невозможно - укажите хотя=бы какую либо часть какой-либо системы (ОС) сохраняющую свое состояние для следующего запуска.

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

И наконец по поводу проекта  http://sourceforge.net/projects/nativeoberon
Это не проект - он стартован 2003-02-26 13:22 и смысл его в выкладке ETH Oberon 2.3.6 на sourceforge и в изменении формата хранения архивов с Arc на Zip. Никакой работы и никаких целей у этого проекта нет.

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


Говорят, что этот эпиграф использовал даже Страуструп. :)

А какие публикации Страуструпа до 1983 г. (статьи Лэмпсона) Вам знакомы?

Боюсь, не потому ли мы "раскололись на два лагеря". :( - Оберон проще. - КП -- надежнее.

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

Беру за основу эпиграф к О-1: "..., но не проще".

Если перефразировать эту мысль, то "во главу угла надо ставить простоту, но при этом иметь чувство меры".

А затем уже -- добиться простоты, устраняя избыточность.

Избыточность в Обероне есть. Почему нет просто LOOP-EXIT без всяких там WHILE, REPEAT-UNTIL? Зачем IF и CASE, если достаточно одного из них?

Именно так, ИМХО, и получился Оберон: путем переработки (рефакторинга :) ) сравнительно сложной Модулы-2.

Не соглашусь. Был "рефакторинг" Cedar средствами "рефакторинга" Модулы-2.

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

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

Ответ на »сообщение 20« (Антон Григорьев)
___________________________

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

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

Это уже слишком отдаёт переходом на личности. Считайте, что предупреждение модератора вы уже получили.

Слово "гуру" можно вычеркнуть. Но ситуация сложная - Руслан высказывает некоторые истины, которые на деле ошибочны и не может подтвердить их примерами. См.## 15,16,17 etc. Это дезинформирует других участников форума.

Ответ на »сообщение 12« (Руслан Богатырев)
___________________________


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

Надеюсь, что обсуждение этого вопроса не перерастет у нас в спор:
- Зеленое!
- Нет, кислое!
:)

Вместе с тем, по тем или иным причинам, этот вопрос показался нам (Руслан Богатырев, Q.Werty, AVC) важным.
Поэтому выскажу свои соображения.
Несомненно, простота является одной из важнейших характеристик Оберона, выделяющей его из длинного ряда императивных языков.
Но, ИМХО, простоту логически нельзя рассматривать в качестве пункта номер один.
Всегда будет возникать вопрос: простота -- чего? Что именно, ребята, у вас просто-то?
Беру за основу эпиграф к О-1: "..., но не проще".
Есть что-то, что важнее даже простоты.
Сначала надо выполнить главные требования, без которых, как-никак, операционную систему не напишешь.
А затем уже -- добиться простоты, устраняя избыточность.
Именно так, ИМХО, и получился Оберон: путем переработки (рефакторинга :) ) сравнительно сложной Модулы-2.
Резюмирую: простота является важнейшей вторичной характеристикой Оберона.
Это как уборка мастерской: вымести стружки, протереть ветошью и т.д. :)
Многие авторы языков этого почему-то не делают, а вот Вирт ценит порядок на рабочем месте. :)

При этом с точки зрения надежности Компонентный Паскаль выглядит более выигрышно, нежели классический Оберон.

Боюсь, не потому ли мы "раскололись на два лагеря". :(
- Оберон проще.
- КП -- надежнее.
- А Оберон -- ПРОЩЕ!
- А КП -- НАДЕЖНЕЕ!!
И т.д.

Интересно, что этот эпиграф Эйнштейна я где-то уже видел. Не только в виртовском каноническом описании Оберона.

Говорят, что этот эпиграф использовал даже Страуструп. :)

Извиняюсь что встреваю в ваши высокие материи со своими приземленным практическим вопросом, но спросить вроде как больше и не где...

Итак вопрос: в реализациях Оберон-систем (а именно: Oberon System, Bluebotle, BlackBox) все модули исполняются в одном и том же адресном пространстве? Т.е. один не безопасный, кривонаписаный модуль вооружившись SYSTEM может легко и непренужденно разрушить всю систему? Это во-первых. Во-вторых: например для BlackBox'a, если конечно все модули живут в одном и том же адресном пространстве, получается что на ВСЕ модули (а модуль в Обероне это часто эквивалент программы в классических системах) отведено всего-навсего адресов под 2 гигабайта? Т.о. в винде под каждую нативную программу отведено 2 Гб адресного пространства, а для ББ-модулей на их ВСЕ отведено всего 2. То есть ББ может использоваться (с небольшими оговорками) как всего лишь ОДНА программа, но не как система (совокупность) работающих программ. Со всеми вытекающими.

Это действительно так?

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


s-expressions и связанная с ними возможность макросов в лиспе!! И ни на каком другом языке на свете !!! :))


А разве таблицы в Lua не близки к S-expressions?

Ответ на »сообщение 15« (Руслан Богатырев)
___________________________
Я поясняю -- вот Оберон-технологии, они собраны в одном месте, не привязаны к конкретному языку.

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

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

Офтопик здесь. Но раз уж вызвали джинна, то не могу удержаться :)) . Не из области функционального, а из области мета-программирования.
s-expressions и связанная с ними возможность макросов в лиспе!! И ни на каком другом языке на свете !!! :))



Представляете, может ведь, негодяй.
...
На самом деле - не может.


Я уже запутался, но это не моя драка. Я лучше отойду :))

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

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

Уважаемый тов.1! На эту роль (гуру) себя не назначал. Более того, к "гуроведению" отношусь скептически. Участвую в форуме наравне с остальными. Если у Вас есть, что сказать про Оберон-технологии -- Ok, говорите. Если есть какие-то конкретные претензии/замечания к моим словам -- Ok, давайте обсуждать.

На самом деле - не может. если возражаете - приведите примерчик со всем состоянием системы.

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

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

Насчет все -- не уверен. Ибо не уверен, что знаю все компиляторы. Что касается примера с XDS -- то это пример и я не утверждал, что можно в нем и только в нем. Кроме того, Вы не учли (возможно, ошибаюсь) маленькой такой мелочи: открывать в тексте -- не значит хранить в тексте. А именно это и являлось предметом критики Jack of Shadows в отношении невозможности использования внешних инструментов контроля версий, которые опираются на работу с обычным текстом. Так что укол не по делу.

2) проблем в реализации такого проекта может быть и нет, но проекта тоже нет (ни одного)

Правда? Ни одного? А какой статус носит этот проект? http://sourceforge.net/projects/nativeoberon

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