Ответ на »сообщение 1385« (Сергей Перовский)
___________________________
Сергей, почему "без наследования"? Мы с Вами много дискутировали по этому поводу, но в чем-то так друг друга и не поняли, видимо. В Компонентном Паскале есть полноценное наследование, точно такое же, как и в других ООП-языках. Речь шла о проектном решении, которое ИНОГДА применияется в СИСТЕМНЫХ задачах - отказе от глубокого наследования реализации, использовании ООП преимущественно для создания асбтрактных разъемов соединения модулей.

По поводу модульности, разницы между модулями и классами и в целом идеологии модульных языков Вирта см.:
http://blackbox.metasystems.ru/index.php?option=com_content&task=blogcategory&id=1&Itemid=51
"Оберон-технологии: что это такое?",
сборник "Физмат ОГУ, Декада науки-2006, секция "Оберон-технологии"
статью "Эволюция императивного программирования" и другие,
а также обсуждение на форуме:
http://bbforum.metasystems.ru/viewtopic.php?t=72

Ответ на »сообщение 1361« (Jean)
___________________________
>>>Правила доступа регулируются вот такой "маленькой" табличкой
Правила доступа чего к чему?
Отказавшись от понятия класса мы естественно получаем всего 2 варианта:
1) Этот же модуль
2) Другой модуль
И правила доступа получились очень простыми.
Вот только цена для многих непомерна. Без понятия класса и наследования многие задачи решать катастрофически неудобно.

Ответ на »сообщение 1376« (Jean)
___________________________
>>>Предлагаю готовить "мирный договор" :))
Ура!
А то аргументы в этой ветке повторяются с каждым новым участником.
Предлагаю компромисные ответы на некоторые прозвучавшие тут вопросы :)

Является ли количество лексем объективным показателем сложности языка? - Да, но только ОДНИМ ИЗ возможных показателей.
Является ли объем библиотеки, входящей в СТАНДАРТ языка весомым аргументом при выборе языка? Да, и по этому показателю авторские языки всегда будут проигрывать. Но они выигрывают в целостности концепции.
Разумно ли объединять единицы компиляции и загрузки? Для некоторых задач - да, для некоторых - нет. Тут все очень неоднозначно.
Являются ли необходимыми механизмы ООП (классы, наследование по реализации и т.д.)? Для некоторых задач - да.
Дженерики это круто? Возможно.
Шаблоны это, вообще, круто? Для кого-то, возможно.
Настоящая модульность - это модульность по Вирту? Вопрос терминологический, как договоримся (или не договоримся).
Модульность (по Вирту), это круче некуда? Многим нравится.... Вопрос в цене, приходится жертвовать многими удобными и полезными механизмами.

Кто продолжит?

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


Предлагаю готовить "мирный договор" :))


В такой формулировке даже я могу его подписать :)

Ответ на »сообщение 1379« (Владимир Лось)
___________________________

Ответ на »сообщение 1345« (pepper)
Можно, но заморочек будет больше. И для Си++/С№ и Явы - тоже больше. Чем в оберонах.

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

P.S. ИМХО, уже всем давно очевидно, что оберон не может быть сразу круче всех языков вместе взятых только потому, что он "простой, безопасный и модульный". Речь может идти только о конкретных областях применения и конкретных задачах.

Ответ на »сообщение 1370« (Max Belugin)

Какие конкретно недостатки у такого решения?

Это решение иной задачи.

Почему классы не являются модулями?

А почему Луна не является Солнцем?

Смысл у них разный. Поймите в чём состоит смысл класса и в чём состоит смысл модуля. Тогда поймёте ответ.
http://blackbox.metasystems.ru/index.php?option=com_content&task=view&id=36&Itemid=15

Уважаемый pepper, судя по Вашим последним фразам:

>> Почему то, что ты описал, невозможно без явной выгрузки модулей, я так и не понял.
>> Вы не захотели причислять C#/Java/Python к числу языков, поддерживающих модульное/компонентное программирование
>> Проблема с пространствами имен высосана из пальца
>> Орловцы - это кто?
>> Т.е., в большом проекте я буду придумывать имена модулям типа ApplicationAdministrativeQueriesBackendCommandsImpl?
>> Пространства имен рулят
>> Не хочу иметь длинные имена модулей и вручную следить за правильным именованием
>> выгружать модули в джаве/C# просто не надо
>> Извини, но такое оценить не смогу (неинтересно)  (по поводу Java, реализованная на Обероне)
>> Перекомпиляция без перезапуска была даже у C++
>> А зачем? Меня "классический" способ разработки вполне устраивает (по поводу выгрузки модулей)
>> мерять сложность в страницах прилагаемой документации тоже некорректно
>> Про рефлексию в "30 страницах документации" тоже написано? Я так понимаю это будет что-то типа: set_catcher( some_proc1 );
>> Можно примерчик? (про процедурные переменные)

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

Ответ на »сообщение 1345« (pepper)
___________________________
Полегче на поворотах.
А "Не стой под стрелой!"...
Орловцы - это кто? Давайте лучше спросим у бобруйчан, которые будут поддерживать проект после орловцев, что они думают по этому вопросу.
Кто-то из нас обладает большей информацией... Факты - в студию!...
Я уже перечислял что именно. А "чего-то эдакое" можно и на брэйнфаке сделать (при сильном желании).
Можно, но заморочек будет больше. И для Си++/С№ и Явы - тоже больше. Чем в оберонах.
Используется VCL фирмы борланд. Вполне тянет на стандартную, учитывая, что других реализаций дельфи в природе нет.
В ББ используется своя - вполне тянет на стадартную, "учитывая, что других реализаций" ББ "в природе нет"...

Ответ на »сообщение 1373« (Max Belugin)
___________________________


а closures в обероне есть? например, можно ли транслировать вот такой код:

function adder(x){
var counter=0;
return function (){
return counter+=x;
}
}
var a1 = adder(1);
var a2 = adder(2);

WScript.Echo(a1());
WScript.Echo(a1());
WScript.Echo(a2());
WScript.Echo(a2());



Нет, closures в Обероне нет.
Впрочем, как и нужды в них, т.к. есть объекты.

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

>>>Ну нельзя формально оценить сложность языка (с человеческой точки зрения) с
>>>позиции лексем и нотации БН
У меня был человеческий пример в #1361. Очень даже человеческий. Даже ребенок может сравнить две "сложности" и сказать, где ее больше. Но этот пример против Вас и поэтому Вы его тихо проигнорировали.