Здравствуйте, GNUzaurus, Вы писали:

GNU>Здравствуйте, Alexandro, Вы писали:

GNU>>> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу.
A>>большие методы прекрасно разделяются компилятором на мелкие.

GNU>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.

А мне нужно чтобы все работало сразу и без багов . Если бы вы были немного грамотнее и смотрели на мир не так однобоко, то поняли бы, что возможностей для маневра в любом случае хватает.

A>> делегаты = интерфейс + анонимный класс. где тут потеря производительности?

GNU> Там и потеря, что в дотнете делегат содержит указатель на функцию. Прежде чем вещать с умным видом — измерил бы сам. Я — измерял разницу в производительности, знаю, о чем говорю.
И как же вы меряли, интересно?
Специально ради тебя написал небольшой тест:

// C#

using System;
using System.Diagnostics;

public delegate void fun();

public class Test {
    
    public static void doF(){
    }
    
    public static void Main(String[] args) {
        fun f = doF;
        
        Stopwatch sw = new Stopwatch();
        sw.Start();

        for(int j = 0; j < 10000; ++j)
            for(int i = 0; i < 10000; ++i)
                f();
        
        sw.Stop();
        Console.WriteLine("time " + sw.ElapsedMilliseconds);
    }
}

// java
public class Test {
    public interface Fn {
        void doF();
    }
    
    public static void main(String[] args) {
        Fn f = new Fn() {
            int val = 0;
               public void doF(){
            }
        };
        
        long time = System.currentTimeMillis();
        
        for(int j = 0; j < 10000; ++j)
            for(int i = 0; i < 10000; ++i)
                f.doF();
        
        System.out.println("time " + (System.currentTimeMillis() - time));
    }
}

скомпилировал, запустил.
результаты:
c# — 650ms
java — 141ms (-server), 297ms(-client)

в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.

A>> INTPTN — каюсь, не знаю что это. и гугл не знает.
GNU> Указатель на функцию.
Поздравляю с изобретением нового термина.

A>>мда, а мужики то не знают, что нельзя и реализуют здесь. Хотя секция ML пуста.
GNU>Учился б ты читать, однако. Мне нужна эффективная реализация, а не тот позорный бред.
тогда пиши свою.

GNU>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада.
A>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
GNU> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
hotspot. хвостовые вызовы будут работать там, где это необходимо.

ЗЫ. бегло проглядел твой профиль. Судя по стилю твоего общения (и не со мной тоже) — ты только что и можешь, что выплескивать свои эмоции на форуме. Логические доводы в твоих рассуждениях отсутсвуют как класс. Пытаясь показаться значительнее, ты кажешься только смешнее. Это мое ИМХО. Общаться с тобой на форуме более не вижу смысла. Если хочешь развеять свои заблуждения — прошу в аську.
ЗЗЫ. для модераторов: прошу прощения за переход на личности. По другому с такими типами я общаться не умею.

Здравствуйте, Alexandro, Вы писали:

Жабист жабисту друк, но истина дороже...

A>Специально ради тебя написал небольшой тест:
A>скомпилировал, запустил.
A>результаты:
A>c# — 650ms
A>java — 141ms (-server), 297ms(-client)

Тест некорректен т.к. в данном случае был просто inline кода. Для того, чтобы он был несколько более правильным, нужно сделать следующее:
1. Нужно несколько реализаций Fun, и они должны использоватся. В этом случае нужны будут виртуальные вызовы. Т.е. тест нужно переписать чтобы было несколько "делегатов" и они все участвовали в тесте.
2. Тело метода вообще пустое. Скорее всего, компилятор его выкинул. Нужно что-то в нем делать более-менее полезное.
3. В java версии нужно делать warmup (см мои посты выше), иначе ты работаешь на интерпретируемом коде некоторое время.

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

Вообще, написать корректный микробенчмарк это очень непростое занятие.

A>в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.

Ты неправ, он по делу критикует JVM. Ограничение на 64к инструкций в методе, отсутствие явной поддержки хвостовой рекурсии и сложность в реализации continuations (хотя, в .NET это делают через хак с yield() который предназначен для другого) это действительно минусы с т.з. ФП языков под JVM. И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.

В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec. Чтобы все это исправить достаточно потратить некоторое кол-во ресурсов, выпустить новую спеку class file format и расширить список инструкций VM. Это вполне можно было бы сделать в одном из minor релизов, но, Sun занят другим. И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг.

В Java есть гораздо более значимые технологические приемущества в т.ч. новомодный escape analysis и thin locks. Но, самое главное это hot spotting, это очень правильный и грамотный подход. Эти вещи гораздо более сложные, интересные и ресурсоемкие чем те мелочи, которые мешают поклонникам ФП спокойно компилироваться в Java byte code.

GNU>>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада.
A>>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
A>hotspot. хвостовые вызовы будут работать там, где это необходимо.

Тут он прав. В Java нет выделенной инструкции для замены одного стекового фрейма на другой и соот-но программа, написанная на другом языке, но компилирующаяся в байт код не может явно указать что здесь нужна хвостовая рекурсия. По хорошему, такую инструкцию действительно надо ввести.

Здравствуйте, Alexandro, Вы писали:

GNU>>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.

A>А мне нужно чтобы все работало сразу и без багов .

У таких, как ты, этого не бывает. Чтоб без сразу багов — это как минимум строгая статическая типизация, с алгебраическими типами данных (да и type classes не повредят). А в ваших Жабках такого не водится, и компилять такие правильные языки под ваши ущербные JVM нереально.

A> Если бы вы были немного грамотнее и смотрели на мир не так однобоко, то поняли бы, что возможностей для маневра в любом случае хватает.

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

GNU>> Там и потеря, что в дотнете делегат содержит указатель на функцию. Прежде чем вещать с умным видом — измерил бы сам. Я — измерял разницу в производительности, знаю, о чем говорю.
A>И как же вы меряли, интересно?

Корректно. А не так по ламерски, как ты. Соблаговоли в следующий раз смотреть на байткод, который из твоих тестов получается. Мы не компиляторы двух корявых язычков сравниваем, а виртуальные машины.

A>в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.

А, с ЛОРа чувачок? Так бы сразу и сказал — я б на тебя тогда время не тратил.

A>>> INTPTN — каюсь, не знаю что это. и гугл не знает.
GNU>> Указатель на функцию.
A>Поздравляю с изобретением нового термина.

.net framework 1.1 его изобрел.

GNU>>Учился б ты читать, однако. Мне нужна эффективная реализация, а не тот позорный бред.
A>тогда пиши свою.

Так в том и засада, что НЕЛьЗЯ написать! Вообще нельзя. Потому что JVM — говно.

GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
A>hotspot. хвостовые вызовы будут работать там, где это необходимо.

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

A> Общаться с тобой на форуме более не вижу смысла. Если хочешь развеять свои заблуждения — прошу в аську.

Пшел вон, щня.

Здравствуйте, n0name2, Вы писали:

N> это действительно минусы с т.з. ФП языков под JVM.

Попрошу заметить, что ФП я почти и не упоминал, упор делал на куда как более мейнстримные задачи — такие как большие ФСМ.

N> И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.

Мейнстрим — безмозгл. Он рулится толпой. Он сам не знает, чего он требует. Он и сборки мусора не требовал, пока ее ему не впарили. Были бы сантехники поответственнее — постарались бы впарить более серьезные вещи.


N>В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec.

Это не главный мой поинт. Даже если я, порвав себе все что только можно, вправлю мозги одной минорной форкнутой веточке Sun JVM, мой код все равно не будет работать ни у жаба-хостеров, ни на KVMах в миллионах мобилок. Так что, мои претензии к авторам ущербной и подлой JVM более чем обоснованы — у меня нет шансов исправить их глупость.

N> И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг.

Ничего в этом настолько важного нет...

N> Но, самое главное это hot spotting, это очень правильный и грамотный подход.

Который в большинстве случаев не годится. Чаще нужен разовый быстрый отклик — а потом метод и не вызовут больше ни разу. Особенно это в софт-риалтаймовых требованиях к UI проявляется. За это Жабку в ГУЙне и не любят.

Здравствуйте, GNUzaurus, Вы писали:

N>>В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec.
GNU> Это не главный мой поинт. Даже если я, порвав себе все что только можно, вправлю мозги одной минорной форкнутой веточке Sun JVM, мой код все равно не будет работать ни у жаба-хостеров, ни на KVMах в миллионах мобилок. Так что, мои претензии к авторам ущербной и подлой JVM более чем обоснованы — у меня нет шансов исправить их глупость.

Участвуй в процессе развития Java, запости патч на OpenJDK, создай JSR на изменение class file format. Спека Java7 еще не утверждена до конца, вполне возможно что туда это войдет.

Попроси коллег и друзей проголосовать за RFE на это изменение.

N>> И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг.
GNU> Ничего в этом настолько важного нет...

Для твоих задач — наверное. Но, в типовом приложении порядка 20% CPU тратится на uncontended lock waits. Escape analysis + thin locks решают эту проблему. В качестве бонуса можно будет чаще делать API thread safe, если их будут использовать в одном потоке, компилятор уберет синхронизацию просто.

Кстати, в .NET, по крайней мере в 2.0 uncontended lock очень дорогой, раза в 4 дороже чем в Java.

На multicore эта проблема вообще стоит во весь рост. Твой язык, компилятор для которого ты делаешь, он вообще shared data предполагает? Или обмен сообщениями?

N>> Но, самое главное это hot spotting, это очень правильный и грамотный подход.
GNU> Который в большинстве случаев не годится. Чаще нужен разовый быстрый отклик — а потом метод и не вызовут больше ни разу. Особенно это в софт-риалтаймовых требованиях к UI проявляется. За это Жабку в ГУЙне и не любят.

Лично меня вообще GUI не волнует совершенно. Для этого есть client VM, ориентированная как раз на такие случаи. Плюс юзай -Xcomp -Xbatch, это хинт JVM что мол — не нужно интерпретатор вообще юзать.

Зато технология позволяет уйти от хранения нативного кода внутири артифактов компиляции а самое главное позволяет делать очень забавные вещи.

Например, если HotSpot знает что есть только одна реализация интерфейса, то она не станет делать вызовы методов виртуальными. А если потом позже мы загрузим в VM новый код, который содержит вторую реализацию, то мы все перекомпилируем и у нас будут виртуальные вызовы. .NET так не может делать by design. Причем, это сложнее исправить чем размер метода или tail rec.

Здравствуйте, n0name2, Вы писали:

N>Ты неправ, он по делу критикует JVM. Ограничение на 64к инструкций в методе, отсутствие явной поддержки хвостовой рекурсии и сложность в реализации continuations (хотя, в .NET это делают через хак с yield() который предназначен для другого) это действительно минусы с т.з. ФП языков под JVM. И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.
yield() — это конструкция языка, к CLR он отношения не имеет и замечательно может быть сделан на JVM.

Здравствуйте, GNUzaurus, Вы писали:

GNU>>> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу.
A>>большие методы прекрасно разделяются компилятором на мелкие.
GNU>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.
Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем нет — лично писал такое. Просто переход на некоторые состояния делается в виде вызова метода.

GNU>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада.
A>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
GNU> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают.

Ничего особого не мешает добавить tail-recursion в Java 7 — свободные байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию.

Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п.

Здравствуйте, Cyberax, Вы писали:

C>yield() — это конструкция языка, к CLR он отношения не имеет и замечательно может быть сделан на JVM.

Конечно можно, не вопрос. Но, для этого нужно ввести новую(ые) инструкцию(ии) в JVM byte code, которые будут оперировать стеком в рамках одного потока. В библиотеках полный аналог yield() не сделать (ну, разве что отдельный поток вводить).

C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете)

Серьезно чтоли? Нифига себе "технологически совершенная виртуальная машина"... Фактически нельзя без перезапуска VM обновить код приложения, например, новую версию webapp положить в IIS... Ужасъ, ф топку

Здравствуйте, Cyberax, Вы писали:

C>Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем нет — лично писал такое. Просто переход на некоторые состояния делается в виде вызова метода.

А в стек срать не стремно?

GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
C>Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают.

Работают. Идеально. Проверял на ВСЕХ версиях. В 2.0 они еще и быстрее работать стали.

Или вы о том, что тупой компилятор тупого C# про них не знает? Так он мне и не интересен нисколько.

C>Ничего особого не мешает добавить tail-recursion в Java 7 — свободные байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию.

Как это аннотацию? Вызовов в методе может быть много, не все будут хвостовыми.

C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п.


Конечо дотнет не идеален. Он вообще — говно. Но по совокупности чуть меньшее говно, чем Жаба.

GNUzaurus wrote:
> C>Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем
> нет — лично писал такое. Просто переход на некоторые состояния делается
> в виде вызова метода.
> А в стек срать не стремно?
А какие проблемы?

Я делал примерно так:

...
static class FSMState
{
    int state;
    int payload;
    ...
}

public int process1(FSMState state)
{
    while(true)
    {
        switch(state.state)
        {
            case 1:
                state.state=doSomeAction();
            case 2:
                state.state=doSomeAction2();
            default:
                if (process2(state)==CONTINUE) continue;
                if (process3(state)==CONTINUE) continue;
                throw YouAreABadBoyException();
        }
    }
}


public int process2(FSMState state)
{
    boolean first=true;
    while(true)
    {
        switch(state.state)
        {
            case 3:
                state.state=doSomeAction3();
            case 4:
                state.state=doSomeAction4();
            default:
                return first?CONTINUE:NOTCONSUMED;
        }
        first=false;
    }
}

Ну и так далее. Естественно, тупой линейный поиск был оптимизирован. Но
общая идея должна быть понятна.

> GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать
> ГАРАНТИРОВАННО.
> C>Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают.
> Работают. Идеально. Проверял на ВСЕХ версиях. В 2.0 они еще и быстрее
> работать стали.
На .NET VM они не реализованы нормально — в Mono намного лучше сделано.

> C>Ничего особого не мешает добавить tail-recursion в Java 7 — свободные
> байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию.
> Как это аннотацию? Вызовов в методе может быть много, не все будут
> хвостовыми.
Ну и помечать "вызов по смещению X — концевой".

> C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot,
> сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM
> есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п.
> Конечо дотнет не идеален. Он вообще — говно. Но по совокупности чуть
> меньшее говно, чем Жаба.
Мне на Parrot VM.

Здравствуйте, n0name2, Вы писали:

N>Здравствуйте, Alexandro, Вы писали:

N>Жабист жабисту друк, но истина дороже...

A>>Специально ради тебя написал небольшой тест:
A>>скомпилировал, запустил.
A>>результаты:
A>>c# — 650ms
A>>java — 141ms (-server), 297ms(-client)

N>Тест некорректен т.к. в данном случае был просто inline кода. Для того, чтобы он был несколько более правильным, нужно сделать следующее:
N>1. Нужно несколько реализаций Fun, и они должны использоватся. В этом случае нужны будут виртуальные вызовы. Т.е. тест нужно переписать чтобы было несколько "делегатов" и они все участвовали в тесте.
N>2. Тело метода вообще пустое. Скорее всего, компилятор его выкинул. Нужно что-то в нем делать более-менее полезное.
N>3. В java версии нужно делать warmup (см мои посты выше), иначе ты работаешь на интерпретируемом коде некоторое время.

N>Но, получившийся код все равно не будет неэквивалентен т.к. делегаты имеют доступ к фрейму функции, которая их вызывает, а анонимные методы — нет (только к константам).

N>Вообще, написать корректный микробенчмарк это очень непростое занятие.

согласен. здесь подробнее описано. Смысл в том, что разница в производительности не существенна в подавляющем большинтсве случаев.

Здравствуйте, n0name2, Вы писали:

N>Здравствуйте, anton_t, Вы писали:

_>>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?

Далее куча перечислений что к чему; хотелось просто поддержать УМНОГО человека, в чем то понимающего.

Основы !

Java = J2ME + J2SE + J2EE |
J2ME — хромает на обе ноги, и даже больше ))
НО на J2SE и J2EE строят МЕГА !!! проекты !!! и говорить что Java хуже — не знать ничего !!!


C# = ASP.NET + WINDOWS FORMS (+ compact framework)
На этом пишут Хорошие сайты, ASP.NET рулит нужно отдать должное, остальное не переносимо, и ничего масштабного вы не увидите , в ближайшем будущем точно ! Новая Виста — это еще одна корова на льду. Но для написания проектов среднего уровня,под Win, вполне подходит.

Теперь скорость !!!
Давайте сравнивать скорость и надежность на нейтральной платформе , так как именно это главные плюсы управляемых , переносимых языков.

ТАК ЧТО КАКУЮ ПЛАТФОРМУ (НЕЙТРАЛЬНУЮ) МЫ ВЫБЕРЕМ !? (Смешно правда ? или подождем еще 3-4 года и тогда соберемся и еще раз сравним ? )

PRV>ТАК ЧТО КАКУЮ ПЛАТФОРМУ (НЕЙТРАЛЬНУЮ) МЫ ВЫБЕРЕМ !? (Смешно правда ? или подождем еще 3-4 года и тогда соберемся и еще раз сравним ? )
Для Java их очень много , а для .NET ...

ВЫВОД (забыл сделать ссори) ! J2SE и J2EE переносимы , .Net — нет )) !!! сравнивать Java'у пока не с чем !!! Модеры, думаю тему можно закрыть ))) .

Здравствуйте, PRoViDeR, Вы писали:

PRV>Здравствуйте, n0name2, Вы писали:

N>>Здравствуйте, anton_t, Вы писали:

_>>>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?

PRV>Java = J2ME + J2SE + J2EE |
PRV>J2ME — хромает на обе ноги, и даже больше ))
PRV>НО на J2SE и J2EE строят МЕГА !!! проекты !!! и говорить что Java хуже — не знать ничего !!!

PRV>C# = ASP.NET + WINDOWS FORMS (+ compact framework)
PRV>На этом пишут Хорошие сайты, ASP.NET рулит нужно отдать должное, остальное не переносимо, и ничего масштабного вы не увидите , в ближайшем будущем точно ! Новая Виста — это еще одна корова на льду. Но для написания проектов среднего уровня,под Win, вполне подходит.

Ты уж определись — в одном посте ты пишешь, что .net не переносим, в другом учитываешь только переносимые фичи. Если добавить непереносимые возможности, то имеем:
+WMI
+COM = вся куча написанных COM-библиотек легко доступна под .net
+MSDTC
+создание на .net хранимок для MSSQL и Orale for Win
+сюда же можно новые фичи приплюсовать: WCF, WWF, WPF

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gregory_krovosos, Вы писали:

VD>Да пойми. Я на Шарпе имею скорость приблизительно как на VC++, простоту выше чем на Яве, качественную среду и отладчик, WinForms, ASP.TET и каждый квартал обновляемый МСДН.

VD>Ты же выдвигая предпосылку о том, что можно работать медленно и не удобно спрашиваеш почему другие так не хотят.

VD>Ты лучше сам ответь, а зачем нужна Ява если у нее нет ни одного приемущества?

Эх.. Программил я на java 2 года, потом 2 года на c#. Поначалу вроде прикольно показалось, но под конец мучительно захотелось снова на java. Что я и реализовал, сменив работу.
Пройдемся по пунктам.
1. "скорость приблизительно как на VC++". Скорость чаще не от платформы зависит, а от прямоты рук.
2. " простоту выше чем на Яве". Категорически не согласен. Java намного проще и понятнее. Некоторые чудо-решения от c# до сих пор меня удивляют.
3. "WinForms". Swing куда удобнее для программиста. Да и со скоростью порешали(хотя, конечно, по скорости отрисовки все равно winForms быстрее. Оно и понятно: свинг использует только рисование примитивов из нативных функций, винформы на 90% нативные). Кстати, сейчас пишем программку на свинге.
4. "качественную среду и отладчик". Ну, с этим в java все отлично .
5. "ASP.NET". Подобных технологий навалом. Это тема для отдельного спора.
6. "каждый квартал обновляемый МСДН". Хелп от МС — одна из моих головных болей. Зоопарк страниц, хрен чего найдешь(почему-то гугл ищет по мсдн в разы лучше собственного уродского поисковика). Нужные знания зачастую находятся совсем не там, где их ожидаешь.

Теперь СЕРЬЕЗНЫЕ недостатки дотнета:
1. Кроссплатформенность, точнее ее отсутствие. Это главная причина, по которой мы сейчас пишем софт на java: переписывать его под win и lin не хочет никто, а железяки, на которые будем ставить, могут поставляться с совершенно непредсказуемыми ОС на борту.
2. Нет исходов самого дотнета + слишком много кода в нативе. Иногда концы ошибки не поймать (особенно это проявлялось при работе с глючным compact framework, особенно с учетом очень куцой документации к нему). Эти NullReferenceException, летящие из глубины фреймворка, и совершенная невозможность посмотреть, где, в каком месте стека, на какой строке, и почему произошла ошибка(а также оттрассировать код фреймворка до этого места в тяжелых случаях), выводили из себя неоднократно. Если бы еще не привычка MS оснащать вылетающие исключения совершенно глупыми коментариями...
3. Мог бы еще про IDE написать, но не буду. 2005 студия продукт неплохой(вот до нее реально было плохо). Если бы еще локальную историю сделали...

Здравствуйте, Eugeny__, Вы писали:

E__>Если бы еще локальную историю сделали...

А что это такое?

Здравствуйте, AndreiF, Вы писали:

E__>>Если бы еще локальную историю сделали...
AF>А что это такое?
http://www.jetbrains.com/idea/features/local_history.html

Здравствуйте, Cyberax, Вы писали:

C>http://www.jetbrains.com/idea/features/local_history.html

Это есть в SlickEdit Tools for Visual Studio
Хотя мне и системы контроля версий хватает

Здравствуйте, AndreiF, Вы писали:

C>>http://www.jetbrains.com/idea/features/local_history.html
AF>Это есть в SlickEdit Tools for Visual Studio
http://www.slickedit.com не открывается Плохой знак.

AF>Хотя мне и системы контроля версий хватает
Локальная история более детальная — там детализируются все операции с кодом. Иногда удобно, чтобы найти из-за чего программа перестала работать после пары сотен строк кода.

Здравствуйте, Cyberax, Вы писали:

C>http://www.slickedit.com не открывается

действительно. это странно