Valery ShiskinНо если приходится разбирать написанный кем-то код или даже свой, то по моему в java все гораздо проще .Ага. Ни делегатов, ни анонимных методов, нихрена...

Valery ShiskinЯ могу использовать Groovy. Причем, вперемешку, в одном пакете. Экзотики здесь масса. А под крылом SpringSource, VMWare и Google Groovy быстро набирает обороты. Когда шло обсуждение новых языковых конструкций для Java 7, было много предложений о кардинальном расширении, но, по всей видимости, благоразумно большинство из них не принято с мотивировкой: Не надо менять язык Java, надо создавать новые языки для ее платформы.Но "на каждый чих" создавать новый язык со своим синтаксисом и особенностями тоже не дело. Те примеры, которые я привёл - это то, чего реально не хватает при работе с, например, типизированными коллекциями (List<T> и т. п.). А это одно из основных применений Java (различные манипуляции с коллекциями в серверах приложений), не так ли? Вот и приходится городить всякие скриптовые механизмы, в которых не производится контроль типов на этапе компиляции. А это, на мой взгляд, очень плохо. Имена полей ещё можно худо бедно заменить строковыми константами, а вот всё остальное...

ЗЫ: yield return тоже весьма полезен.
ЗЫ2: Как-то искал достойную замену дотнетному Nullable<T>. Тоже чё-то мне там не понравилось, что конкретно - не помню. :-)

Valery ShiskinПриведу пример. Когда мне понадобилось работать с офисными (MS Office) приложениями, используя VS Office Toolkit (возможно, название не совсем точное), то C# оказался крайне неудобным. Пришлось изучать VB .Net. Так что, язык на все случаи жизни не существует.Есть такое. Приходится писать "обёртки" вокруг офисных классов. Возможно в моих случаях масштабы бедствия были не столь серьёзны, поэтому я не делаю из этого проблемы. :-)

Valery ShiskinКогда шло обсуждение новых языковых конструкций для Java 7, было много предложений о кардинальном расширении, но, по всей видимости, благоразумно большинство из них не принято с мотивировкой: Не надо менять язык Java , надо создавать новые языки для ее платформы. Интересна мотивировка для выделенного тезиса. Может это связано с какими-то проблемами, из-за которых невозможно расширять возможности Java?

chpashaЛеха ты тоже чтоль на яву перешел :)) ?Да чё-та сгущаются тучи. Возможно придётся перейти. Вот и пытаюсь понять что меня ждёт. :-)

chpashaкак всегда за обратную совместимость борются.В сишарпе появилась куча новых конструкций, однако с обратной совместимостью всё в порядке. Парадокс. :-)
chpashaдо сих пор не пойму, как можно было имея с++ в примере не ввести генерики в язык с самого начала. спешили видать пятилетку за 3 года сбацатьДа и Микрософт в этом отношении не лучше. В итоге все библиотеки можно условно поделить на две части, до дженериков, и после их появления.

Окак
автор>> В Java generic'и просто работают как "автоматический вставлятель кастов". То есть, ArrayList<Integer> и ArrayList<String> в байт-коде будут реально одним и тем же ArrayList, хранящим Object'ы.
>И почему это плохо? Необходимость преобразования встроенных типов к объектам (boxing) никак с этим не связана.

В .NET _реально_ может создаваться тип, который хранит не забоксированые примитивы, а реальные value-типы. Это дает реальный выигрыш в скорости и памяти.

В Java это невозможно - все обобщенные контейнеры вынуждены храить Object'ы, что требует обязательного боксирования. Причем, защиту generic'ов очень просто пробить.

Вот это скомпилируется без ошибок:
========
ArrayList<Integer> test=new ArrayList<Integer>();
ArrayList test2=test;

ArrayList<Float> test3=(ArrayList<Float>)test2;
Float first=test3.get(0); //Упс... В runtime получим ClassCastException
========