Ну то, что вендор перестанет существовать в случае с МС неважно. МС еще нас и наш софт переживет.
Насчет конкуренции — тут как раз и конфликт, спецификация одна, значит все должно работать одинаково.
Как только появляются плюшки у того или иного вендора — получается вендорная зависимость — в чем отличие от МС?
> Google все-таки очень удачно удалось разжечь войну за производительность браузеров.
Просто ему больше всех нужен производительный JS, чтобы захватить нишу офисных приложений.
Идея Google подсадить всех на свои cloud решения, что отвяжет выбор клиентской ОС от Windows.
И таким образом, лет за 5-10 убить дойных коров МС.
В итоге имеем «те же яйца, вид сбоку». Будем все писать не Micro$oft, как сейчас, а G$$gle :)
Любой разумный человек понимает, что МС никуда не денется ближайшие 10 лет, что Inter/AMD никуда не денутся.
Цена МС-прослойки — 2 человекочаса — смех да и только.
А жизненный цикл любого софта ненастолько высок, чтобы вообще париться на тему кросс-платформенности.
Мобильные оси — другое дело, но опять же никто не мешает писать клиентский софт на .NET для большинства *никсов, если кого-то сильно приспичит.
Хотелось бы знать, чего есть в Java платформе такого, чего нет в .NET?
Ничего не имею против того, что Microsoft — большая и богатая фирма (видимо неспроста).
Но пускай апологеты Java объяснят мне почему нет единого грамотного хозяина, который бы следил и не допустил бы того бардака в Java индустрии. Почему нельзя сделать один, но нормальный AppServer, одну, но нормальную RDBMS, один, но нормальный web-framework?
Скольно на Java веб-фреймворков? А сколько реально юзабельных и не морально устаревших?
Не буду конечно за всю Германию говорить, но по моему немалому опыту — .NET набирает силы и на server-side.
Ставятся Windows фермы, пишется грамотный софт на .NET, на ASP.NET, на WCF.
И это финансовый сектор, где деньги умеют считать.
Ну после вкусностей C#, всяких там extensions methods, linq, expression trees, closures и т.д. писать на Java реально поднадпрягивает :)
Продуктивность C# уже на порядок выше, а через два месяца выйдет новый шарп.
Поскольку hash не является уникальным, один и тот же hash могут иметь несколько объектов.
Это значит, что в группе элементов под одним hash-ем нужно делать полный перебор ключей.
При плохом алгоритме вычисления hash, группы могут получаться очень большие, в таких случаях вставка будет неоправданно дорогая.
В red-black-trees деревья балансируются, поэтому поиск всегда быстрый и вставка всегда одинаково производительна.
Мне почему-то кажется, что добавление дешевле. Потому как раздвигать километровые массивы не нужно, нужно просто создать ноду и переписать пару поинтеров.
Бинарный поиск vs подсчет хэша и полный перебор группы — сложно сказать, что быстрее.
А вот памяти — да, памяти нужно больше. Но это оправдывает то, что эта память будет garbage collected, ибо не LOH :)
Пардон, я имел ввиду SortedDictionary<K,V> — этот класс использует red-black tree индексы, которые строятся из небольших node-классов, которые точно не попадут в LOH
1) А правда, что чтобы List<object> попал в LOH, в него надо насовать 4 миллиона объектов.
2) А правда, что чтобы List<double> попал в LOH, в него надо напихать 2 миллиона даблов.
3) МС рекомендует использовать object вместо struct, начиная с 16 байтного размера. Стоит ли овчинка выделки тогда?
Насчет конкуренции — тут как раз и конфликт, спецификация одна, значит все должно работать одинаково.
Как только появляются плюшки у того или иного вендора — получается вендорная зависимость — в чем отличие от МС?
Просто ему больше всех нужен производительный JS, чтобы захватить нишу офисных приложений.
Идея Google подсадить всех на свои cloud решения, что отвяжет выбор клиентской ОС от Windows.
И таким образом, лет за 5-10 убить дойных коров МС.
В итоге имеем «те же яйца, вид сбоку». Будем все писать не Micro$oft, как сейчас, а G$$gle :)
Любой разумный человек понимает, что МС никуда не денется ближайшие 10 лет, что Inter/AMD никуда не денутся.
Цена МС-прослойки — 2 человекочаса — смех да и только.
А жизненный цикл любого софта ненастолько высок, чтобы вообще париться на тему кросс-платформенности.
Мобильные оси — другое дело, но опять же никто не мешает писать клиентский софт на .NET для большинства *никсов, если кого-то сильно приспичит.
Про RDBMS — ну это из темы МС vs Java+open source
Странно, что в русскоговорящем Google выглядит все еще белым и пушистым.
Захожу на Хабр и каждый раз удивляюсь :)
Ничего не имею против того, что Microsoft — большая и богатая фирма (видимо неспроста).
Но пускай апологеты Java объяснят мне почему нет единого грамотного хозяина, который бы следил и не допустил бы того бардака в Java индустрии. Почему нельзя сделать один, но нормальный AppServer, одну, но нормальную RDBMS, один, но нормальный web-framework?
Скольно на Java веб-фреймворков? А сколько реально юзабельных и не морально устаревших?
Ага, вот оно чё… (С) Светлаков
Ставятся Windows фермы, пишется грамотный софт на .NET, на ASP.NET, на WCF.
И это финансовый сектор, где деньги умеют считать.
Продуктивность C# уже на порядок выше, а через два месяца выйдет новый шарп.
Короче, C# 3.0 покрыл функциональное программирование, C# 4.0 покрыл динамическое.
Look no more.
www.ambiera.at/copperlicht/demos/demo_quakelevel_external.html
Что я делаю не так?
Должна быть возможность узнать, является ли число NaN, иначе смысле в NaN — нет
Это значит, что в группе элементов под одним hash-ем нужно делать полный перебор ключей.
При плохом алгоритме вычисления hash, группы могут получаться очень большие, в таких случаях вставка будет неоправданно дорогая.
В red-black-trees деревья балансируются, поэтому поиск всегда быстрый и вставка всегда одинаково производительна.
Бинарный поиск vs подсчет хэша и полный перебор группы — сложно сказать, что быстрее.
А вот памяти — да, памяти нужно больше. Но это оправдывает то, что эта память будет garbage collected, ибо не LOH :)
85Кb это около 21 тысяч объектов в списке, или 10 тысяч даблов.
Не настолько астрономические, но все равно, достаточно нереальные размеры массивов в прикладных задачах.
Присоединяюсь к мнению, что Dictionary<K,V> спасет и от LOHов, и от медленного поиска объекта по ключу :)
2) А правда, что чтобы List<double> попал в LOH, в него надо напихать 2 миллиона даблов.
3) МС рекомендует использовать object вместо struct, начиная с 16 байтного размера. Стоит ли овчинка выделки тогда?
Под большими объектами подразумеваются массивы T[].
Идея автора порезать массивы на более мелкие массивчики, чтобы они не попадали в LOH.
Если в LOH после 16мб, то возникают следующие вопросы:
1) А правда, что чтобы List
Неужели ввтор научился перегружать оператор new в C#?