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

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

Это не просто сайт про BlackBox. Это хорошо известный центр компетенции BlackBox в России.

Ответ на »сообщение 864« (Сергей Губанов)
___________________________


Ого! Внести изменение в базовый класс!!!
Да тут перезагрузка - это цветочки.
Боюсь как бы вдруг не понадобилась перекомпиляция классов-расширений.

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

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

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

Ого! Внести изменение в базовый класс!!!
Да тут перезагрузка - это цветочки.
Боюсь как бы вдруг не понадобилась перекомпиляция классов-расширений.

Насчет того, что многие программисты проходят мимо Оберона.
К счастью некоторые не проходят :).
Случайно наткнулся на любопытный сайт ОЦПИ "Метасистемы", где программисты не только не проходят мимо, но даже осознанно выбирают именно Оберон/BlackBox. Желаю им всем удачи.
http://blackbox.metasystems.ru

Ответ на »сообщение 857« (Сергей Губанов)
___________________________


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


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

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

Например, ведь не все согласны с необходимостью отдельной конструкции для модуля. Тот же Мейер, например. Почему?

Модули в Обероне -- главное средство контроля над сложностью. Это осознанный отказ от мирских соблазнов. Они не наследуются, не параметризуются, не обобщаются в виде generic-сущностей. Просто "тупые" ящики с "разъемами" для контактов. Больше ничего. Вся сложность ООП зашита внутри. Внутри саркофага под именем модуль.

Это ключевая и принципиальная вещь. Если при таких жестких ограничениях можно создавать сколь угодно сложные системы и иметь функциональный эквивалент той же Java -- все остальное уходит на задний план.

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

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


Поскольку в Juice технологическая цепочка написания Оберон-аплетов была завязана на Oberon System 3 (Франц все годы отвечал за Mac'овскую реализацию Оберона), пришлось еще раз возвращаться к освоению системы. На этот раз все было не так напряжно. А когда освоил -- оценил и саму систему. Причем, чем дальше изучал и пробовал, тем больше восхищался. Да это же кладезь премудрости. И куда я раньше-то смотрел?

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

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

<...>

При этом примерно могу себе представить, как сложно идти к простоте Оберона не от родственной ему Модулы-2, а от других языков. Особенно в наше время, когда сплошь и рядом такое всё красивое и блестящее. Одно прямо-таки лучше другого. Глаз не нарадуется.


Спасибо!
Примерно об этом и хотелось узнать.
Насколько я понял, только углубление в операционную систему позволило по настоящему оценить Оберон.
Так что не приходится удивляться, что язык Оберон непопулярен.
На поверхности - его "бедность" (нет "наворотов").
Если добавить сюда отсутствие (например, у нас в России) печатных изданий, полное отсутствие спроса на Оберон-программистов...
Шансов на популярность никаких.
Возникла мысль, что было бы очень неплохо провести показательный сравнительный анализ обероновских и некоторых современных программных систем.
Без такого анализа подавляющее большинство программистов пройдет мимо.
А это очень жаль.

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

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

Это верно. Есть язык Оберон, а есть технология Оберон. Примерно так, как это обстоит с Java. Оберон-технология включает в себя не только и не столько подходы в отношении РЕАЛИЗАЦИИ языка, сколько решения по созданию на его основе нетривиальных систем. Примерами которых могут служить Oberon System и BlackBox.

Итак, есть Оберон-решения, которые очень неплохо документированы в книгах Вирта-Гуткнехта-Рейзера и BlackBox-документации. Причем вариативные решения. Все это в тщательно документировано и есть исходных текстах.

В 2002 г. проф. А.А.Шалыто (благодаря которому в СПбГУ ИТМО вручили докторскую мантию Вирту, а теперь вручают Мейеру) выдвинул инициативу об организации
%url[движения за открытую документацию.] http://ru.wikipedia.org/wiki/%D0%94%D0%B2%D0%B8%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%83%D1%8E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BD%D1%83%D1%8E_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D1%86%D0%B8%D1%8E

Это не голый OpenSource и не документирование API. Это детальное документирование проекта. Где исходники -- лишь иллюстрация. Подробнее см. http://is.ifmo.ru/belletristic/
Вот уже несколько лет студенческие проекты в рамках этого движения публикуются на дисках "Мира ПК".

Оберон-технология и ее документирование -- предвестники этого движения.

Дополнение про модули.

Почему невозможно создать аналог BlackBox работающий на платформе .Net?

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

Представьте себе на мгновение, что было бы если бы в BlackBox отсутсвовали пункты меню "Dev/Unload" & "Dev/Compile And Unload". Вам бы приходилось перезапускать весь BlackBox каждый раз, когда Вам было бы нужно перезагрузить какой-то модуль.