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

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

• Полная безопасность типов (обероновских; во многих оберонах нет перчислимого типа и т.п.) и защита памяти. info21 хорошо назвал это свойство "герметичностью".
  
• Сборка мусора (нет утечек и повисших указателей).
  
• Наличие рефлексивного рантайма (если вдруг "припрет" нужда).
  

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

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

Что касается отказа от наследования реализации, то в Вашем случае (ИМХО) это ограничение смело можно отбросить.
Ведь Вы и правда пишете не ОС, а отдельное приложение.

Ответ на »сообщение 1729« (Снегурочка)
___________________________
>>>Здравая мысль, давайте и начнем с Вашего тезиса: Модульный подход к программированию плохо совместим с ООП и аргументы типа "Оберон позволяет строить иерархии объектов" не катят. Как насчет его аргументации? Можно пообсуждать.
Уже обсуждалось. Но давайте попробуем еще раз.

В качестве сильного аргумента в пользу модульного программирования приводится динамическая загрузка/выгрузка модулей, с возможностью заменя неактивных модулей без остановки всей системы. Некоторые именно в этом видят суть Оберон-технологии.
Я понимаю, что для некоторого слоя общей среды, вроде .NET это очень полезное качество. Это не системное программирование в старом смысле т.к. это не работа с железом, но это и не прикладные задачи. С точки зрения программиста прикладника это верхний слой операционной системы. Переход от dll к модулям с мощным контролем совместимости безусловный плюс.
Какие ограничения вытекают из динамической перезагрузки. Такие же, как от использования dll - наследование через границы модулей недопустимо. Оговорюсь, я имею в виду наследование по реализации. Без него от ООП остается набор красивых слов.
Либо ООП, либо динамические модули.
Я в основном занимаюсь имитационным моделированием, ради которого когда то и было придумано ООП. Поэтому крайне осторожно отношусь к утверждению, что от него надо отказатся, как от устаревшей идеологии. Я пытаюсь представить себе, во сколько раз вырастет текст моей системы, если в каждом модуле мне придется писать всю функциональность очередного класса от нуля. Причем это будет высмеиваемый всеми copy/past в чистом виде.
Что я слышу в ответ? Пиши свое наследование, тебе ведь не нужно, чтобы твои модули могли изменяться независимо. Но тогда в чем выигрыш? Зачем писать в ООП стиле на языке, который своим синтаксисом демонстрирует неуважение к ООП? Отсутствие ключевого слова class это не просто минимализм. Да можно обойтись - писал я в ООП стиле на чистом Паскале. Но мне гораздо проще научить ООП при помощи языка, в котором понятие класс введено явно, чем объяснять отдельно идеологию и отдельно, как это реализовать при помощи рекордов и функций, зависимых от типа.
Мне многое нравится в синтаксисе Оберона, Вирт многое по сравнению с Паскалем доработал. Но то, что тут называют Оберон-технологией, представляется мне достаточно узкоспециализированным инструментом - инструментом для коллективной разработки системного окружения. Нужен ли нам настолько еще один .NET, чтобы под это создавать инструментарий разработки?
Может я чего-то не понимаю, но постоянные восторги, насчет изменений без перекомпиляции указывают именно(и только) на эту область применения. Ну нет у большинства прикладных программистов потребности изменять что-то без перекомпиляции. 

Ссылку на статью "Zero-Overhead Exception Handling Using Metaprogramming" можно найти в статье Википедии, посвященной исключениям:
http://en.wikipedia.org/wiki/Exception_handling
Ссылку дают также здесь:
http://www.answers.com/topic/exception-handling

Ссылку на эту статью можно найти и в более новых работах.
http://www.patentstorm.us/patents/6848111.html

Вот адрес статьи на сайте университета г.Линца (в постскриптовском формате):
http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b/paper.ps.Z

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

RTS вызывает HandleEof в случае, когда было выброшено исключение.


Точнее, библиотечная процедура Exceptions.Raise находит ближайший обработчик исключений, пользуясь метапрограммными средствами обероновского (или иного) рантайма (например, райдерами, определенными в модуле Ref; для КП, наверное, можно использовать модуль Meta).
Плюсы такого решения:

• простота реализации (опять-таки :) );
  
• отсутствие дополнительных временных затрат (overhead) в случае, если исключение не возбуждается;
  
• возможность использовать не только семантику завершения (в отличие от Си++ и Явы).
  

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

Возвращаясь к старой статье Мессенбека и Пиркельбауэра "Zero-Overhead Exception Handling Using Metaprogramming", приведу пример обработки исключения (с помощью метапрограммирования) из этой статьи:

PROCEDURE Foo (): INTEGER;
  VAR f: File; ch: CHAR;
  PROCEDURE HandleEof (VAR eof: EofException): INTEGER; (*the handler*)
  BEGIN
    Close(f);
    RETURN 1 (*error code for eof*)
  END HandleEof;
BEGIN (*Foo*)
  Open(f, "…");
  REPEAT Read(f, ch); … UNTIL …;
  Close(f);
  RETURN 0 (*no error*)
END Foo;

PROCEDURE Read (f: File; VAR ch: CHAR);
VAR eof: EofException
BEGIN
  IF …end of file … THEN Exceptions.Raise(eof) ELSE … END
END Read;

Конечно, пример схематичный.
Но он показывает, как можно (в принципе) обрабатывать исключения без деструкторов и явного включения новых ключевых слов в язык. Т.е. этот способ применим даже к Оберону-1. (RTS вызывает HandleEof в случае, когда было выброшено исключение.)
Кстати, этот подход реализован в ETH Oberon.
Конечно, можно добавить в язык новые ключевые слова.
Например, в Зонноне:

begin
...
on exception do
...
end

(В XDS Oberon-2 можно использовать ключевое слово EXCEPT.)

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


Если не считать финализацию и вход/выход в критическую секцию в Активном Обероне и Зонноне (EXCLUSIVE и т.д.), то, пожалуй, никак.
Вопрос был поставлен так: как Оберон помогает освободить ресурсы (не память) при выходе из функции. Видимо, в вопросе содержится намек на деструкторы Си++ и т.п.
Вопрос показался бы мне совсем неинтересным (ИМХО, не стоит "городить" деструкторы только для того, чтобы с их помощью освобождать ресурсы, выделенные в той же самой функции), если бы не связь деструкторов (в Си++) с обработкой исключений (принцип "выделение ресурса есть инициализация").
Известно, что собственно "бросать" и обрабатывать исключения можно и без языковых конструкций вроде try, throw, catch.
Но хотелось бы хорошо представить себе механику "отката" без деструкторов.
Здесь надо подумать.

Пока просто немного предварительной "информации для размышления".
Деструкторы:
http://en.wikipedia.org/wiki/Destructor_(computer_science)
Принцип "выделение ресурса есть инициализация":
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
Финализаторы:
http://en.wikipedia.org/wiki/Finalizer
В КП финализаторы поддерживаются на уровне языка:

PROCEDURE (p: ANYPTR) FINALIZE;

В языках со сборкой мусора деструкторов обычно нет.

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


Система мониторинга ГЭС - это конечно реальная задача, спору нет. Только сделана она не на обероне-1 и не на обероне-2 и даже не на компонентном паскале, а на блэкбоксе (ББ). Возможно ББ действительно большой шаг на пути к очеловечиванию оберона. Только ББ - это уже не язык, а среда. Это среда привязана к конкретной конторе и конкретной платформе.

Вместе с тем, ББ целиком и полностью написан на КП (а КП, в свою очередь, есть вариация Оберона-2).
По сути, ББ -- прямой потомок ОС Оберон.
Т.е. различия КП и языка Оберон, а также ББ и ОС Оберон не так уж велики.


Последний из неотвеченных вопросов (который задал не только я) был такой: как оберон помогает мне управлять ресурсами (помимо памяти).

Если не считать финализацию и вход/выход в критическую секцию в Активном Обероне и Зонноне (EXCLUSIVE и т.д.), то, пожалуй, никак.
Вопрос был поставлен так: как Оберон помогает освободить ресурсы (не память) при выходе из функции. Видимо, в вопросе содержится намек на деструкторы Си++ и т.п.
Вопрос показался бы мне совсем неинтересным (ИМХО, не стоит "городить" деструкторы только для того, чтобы с их помощью освобождать ресурсы, выделенные в той же самой функции), если бы не связь деструкторов (в Си++) с обработкой исключений (принцип "выделение ресурса есть инициализация").
Известно, что собственно "бросать" и обрабатывать исключения можно и без языковых конструкций вроде try, throw, catch.
Но хотелось бы хорошо представить себе механику "отката" без деструкторов.
Здесь надо подумать.

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

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

Здравая мысль, давайте и начнем с Вашего тезиса: Модульный подход к программированию плохо совместим с ООП и аргументы типа "Оберон позволяет строить иерархии объектов" не катят. Как насчет его аргументации? Можно пообсуждать.

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

Система мониторинга ГЭС - это конечно реальная задача, спору нет. Только сделана она не на обероне-1 и не на обероне-2 и даже не на компонентном паскале, а на блэкбоксе (ББ).

Как Вы думаете, можно ли такую систему сделать на Си? А почему, тогда, скажите на милость, ее НЕЛЬЗЯ сделать на Обероне-1? Нет, ну если мы начнем задаваться проблемами менеджмента и рассуждать о целесообразности выбора инструментария для данного проекта с учетом оптимизации стоимости, сроков и качества (наличия кадров, проблем сопровождения, интеграции и т.п.), то зайдем в сферы, имеющие отдаленное отношение к самим обсуждаемым языкам.

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

Ответ на »сообщение 1723« (пачимучкин )
___________________________

А без популяризации не будет и перспектив у "Оберон-технологий".

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

Если для человека отсутствие enumeration в языке критично, если он не видит сути языка в чистой, препарированной форме, его важнейших отличий от других, то чем туда затащит какой-то GUI? Бирюльками? ОС Bluebottle в свое время увлеклася такими штучками. И что, много народу туда пошло из-за красивости бирюлек? Тыщи и тыщи?

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

Айс? Не-а, не Айс!

Позвольте задать Вам простой вопрос: что такого интересного и полезного Вы для себя лично нашли в Обероне? Неужели этого добра нет в других языках?