>>>Можно и без фичи, но с фичей приятнее
Предлагаю готовить "мирный договор" :)) А то дело дошло уже до выискивания "блох". У кого что есть, у кого чего нет, у кого больше, у кого меньше. Это уже тупиковая ситуация. Сегодня в Оберонах чего-то нет, завтра глядишь уже есть, хоть и под другим названием (ActiveZonnon или что-нибудь в этом роде). Аналогично, и для Java/C#.
Итак, что уже очевидно?
1) Языки программирования бывают разные.
2) Любой программист какие-то знает и любит, какие-то знает и не любит, какие-то не знает и не любит
3) Каждый язык имеет право на жизнь
4) Есть две философии в программировании:
- 1. Можно и без фичи, но с фичей приятнее ("C#")
- 2. Если можно без фичи, то лучше без фичи ("Oberon")
5) Любая "философия" имеет право на жизнь.
Конец :)

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


Если мы сравним формальное описание грамматики в нотации Бэкуса-Наура, то Оберон все равно будет впереди.


Будет тоже самое, что и с лексемами.


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


Ну нельзя формально оценить сложность языка (с человеческой точки зрения) с позиции лексем и нотации БН. Я показал абсурдность этого на примере. Это некорректный способ дискуссии?

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


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


Про рефлексию в "30 страницах документации" тоже написано? Я так понимаю это будет что-то типа:
set_catcher( some_proc1 );
set_finalizator( some_proc2 );
do_some_with_throw_exception();

Не впечатляет. Решение из той же серии, что и "GC для C++".


Насчет делегатов. В Обероне существуют процедурные переменные.


Можно примерчик?


Что касается перегрузки операторов, вопрос в том, хорошо это или плохо.


Понятно, проехали.


Какие именно элементы функционального программирования в шарпе кажутся Вам жизненно важыми?


Жизненно - никакие. Тут так же как и с пространствами имен. Можно и без фичи, но с фичей приятнее.

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


В Обероне существуют процедурные переменные.


а 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());

C:>cscript test.js
Сервер сценариев Windows (Microsoft R) версия 5.6
c Корпорация Майкрософт (Microsoft Corp.), 1996-2001. Все права защищены.

1
2
2
4

>>>Я всего лишь хотел показать, что мерять сложность в страницах
>>>прилагаемой документации тоже некорректно.

Если мы сравним формальное описание грамматики в нотации Бэкуса-Наура, то Оберон все равно будет впереди.

>>>Так же как и в лексемах мерять бессмысленно. А то окажется, что
>>>самый простоя язык это - "10101010000111110101010".

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

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

Мерять библиотеки в любом случае бессмысленно - количество компонентов в составе библиотеки не имеет никакого отношения к сложности языка.


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

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


Так же как и в лексемах мерять бессмысленно. А то окажется, что самый простоя язык это - "10101010000111110101010".


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


Так в чем критерий? И где граница между простотой и примитивизмом?

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

Ответ на »сообщение 1332« (Max Belugin)
Можно выгружать компоненты при желании: http://www.rsdn.ru/article/dotnet/appdomains.xml

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


1. Я могу запустить dll в виде исполняемого процесса?
2. Я могу использовать dll в виде AppDomaina
3. Нужно ли мне будет вносить модификации в сборку в обоих случаях?
4. Почему dll загруженная посредством appDOmain это не модуль?
5. Какие конкретно недостатки у такого решения?


Ответ на »сообщение 1340« (Max Belugin)
кстати в жабе тоже можно анлоадить http://blog.taragana.com/index.php/archive/how-to-unload-java-class/

Вообще-то известно, что код классов в Java удаляется сборщиком мусора. Но это не имеет отношения к выгрузке модулей. К тому же классы модулями не являются.


1. По ссылке приводится пример томкат, который перезагружает вебприложения.
2. Почему классы не являются модулями?

Ответ на »сообщение 1363« (Илья Ермаков)
___________________________


Покажите мне аналог BlackBox под .NET. Я там увидел только классическую среду, работающую по принципу "пишем в Студии, компилируем, запускаем как отдельное приложение, возвращаемся в Студию, исправляем, компилируем, перезапускаем" и т.п.


Перекомпиляция без перезапуска была даже у C++ начиная с VC6.0 и далекого 1998 года (когда дотнетом и не пахло). Так что есть подозрение, что чего-то ты недоглядел.


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

А зачем? Меня "классический" способ разработки вполне устраивает. Я не говорю, что он лучше, чем в BB, я просто не вижу преимуществ у ничего мне не говорящих "составных документов". Можно пример на пальцах?

>>>Учитывая отсутствие стандартной библиотеки (которая могла бы входить в
>>>описание языка, как у всех нормальных языков) обсуждать действительно
>>>нечего.
Мерять библиотеки в любом случае бессмысленно - количество компонентов в составе библиотеки не имеет никакого отношения к сложности языка.
Вы опять сделали вид, что "не поняли". Подсчитайте количество лексем и грамматических правил в Яве и в Обероне. Это и будет показатель сложности языка. Впрочем можете не делать этого - по критерию сложности, точнее "простоты", Оберон дает 100 очков вперед любому языку универсального назначения.

Ответ на »сообщение 1362« (Илья Ермаков)
___________________________

авные документы BlackBox. Поэтому работает крайне быстро.
http://djone.ru.


Очень красивый сайт. Откуда качать на помотреть?


Java, реализованная на Обероне - вещь обыденная.


Извини, но такое оценить не смогу (неинтересно). Есть что-нибудь на пощупать и с исходными текстами?