Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 241
В сравнении с плюсовым кодом таки C#/Java/etc жрут больше. Особенно если ты умеешь писать более менее корректный плюсовый код. Насчет сборки мусора: все конечно прекрасно, но кто мешает таким же образом работу с кучей в C++ оптимизировать таким образом, чтобы delete лишь помечал блок памяти как ненужный, а удалялся он уже в тот момент, когда это наиболее уместно. deleteLater() в Qt как раз работает по этому принципу.
Не, я считаю неуместным обсуждать и сравнивать С++. Я привел типичные заблуждения относительно C#, и факты касательно него же, и ничего большего. И это… Qt != C++ в любом случае
абсолютно несогласен, Qt==С++ как раз таки, также как и Objective C == C, но не наоборот естественно. Qt — это С++ фреймворк чистой воды, как он может не быть C++ ??? или по вашей аналогии boost != С++? или GTK != C?
А по теме, подняли кучу спорных вопросов и даже не смогли их нормально аргументировать, например пунк про отжирание памяти и сравнивается с Руби. Я не уверен что Руби является таки эталоном экономичности памяти. А программа отъедающая 100-150 метров памяти должна иметь очень и очень и очень везкие оснвоаняи для этого (это мое мнение).
По поводу сборщика мусора и его скорости. Вы нписали что С++ программа может выйграть по производительности если правильно управляется память и нет багов. Друг мой. Это же касается и менеджмент кода, сборщик мусора не панацея и память можно «загадить» в обоих случаях с одинаковым успехом. А неправильно управление памяти в С++/С коде является неправильным использвоанием этих языков аппрори и как аргумент не рассматривается.
Ну и можно продолжать и продолжать и так далее
А по теме, подняли кучу спорных вопросов и даже не смогли их нормально аргументировать, например пунк про отжирание памяти и сравнивается с Руби. Я не уверен что Руби является таки эталоном экономичности памяти. А программа отъедающая 100-150 метров памяти должна иметь очень и очень и очень везкие оснвоаняи для этого (это мое мнение).
По поводу сборщика мусора и его скорости. Вы нписали что С++ программа может выйграть по производительности если правильно управляется память и нет багов. Друг мой. Это же касается и менеджмент кода, сборщик мусора не панацея и память можно «загадить» в обоих случаях с одинаковым успехом. А неправильно управление памяти в С++/С коде является неправильным использвоанием этих языков аппрори и как аргумент не рассматривается.
Ну и можно продолжать и продолжать и так далее
Несогласны с чем? С тем, что я не хочу обсуждать C++ в топике про C#? Странная точка зрения.
То, что вы ответили по теме, я, если честно, не понял.
>> Я не уверен что Руби является таки эталоном экономичности памяти
Мне кажется, я не говорил про эталоны и про абсолютную меру. Это всего лишь пункт к тому, что CLR кушает сравнимо с другими технологиями.
>> подняли кучу спорных вопросов и даже не смогли их нормально аргументировать
Ну, тут вы занимаетесь демагогией. Это не вопросы, это заблуждения, заведомо некорректные мнения. Их не надо аргументировать, на них надо отвечать, подкрепляя ссылками. Я это сделал
>> Это же касается и менеджмент кода, сборщик мусора не панацея и память можно «загадить» в обоих случаях с одинаковым успехом. А неправильно управление памяти в С++/С коде является неправильным использвоанием этих языков аппрори и как аргумент не рассматривается.
Вы тут сами себя опровергаете. Ну в том смысле, что по аналогии я могу сказать, что неправильная работа с GC не рассматривается и входит в знание языка.
Пойнт в том, что в случае с GC сделать неправильно гораздо, гораздо сложнее.
>> можно продолжать и продолжать
Отлично, продолжите.
То, что вы ответили по теме, я, если честно, не понял.
>> Я не уверен что Руби является таки эталоном экономичности памяти
Мне кажется, я не говорил про эталоны и про абсолютную меру. Это всего лишь пункт к тому, что CLR кушает сравнимо с другими технологиями.
>> подняли кучу спорных вопросов и даже не смогли их нормально аргументировать
Ну, тут вы занимаетесь демагогией. Это не вопросы, это заблуждения, заведомо некорректные мнения. Их не надо аргументировать, на них надо отвечать, подкрепляя ссылками. Я это сделал
>> Это же касается и менеджмент кода, сборщик мусора не панацея и память можно «загадить» в обоих случаях с одинаковым успехом. А неправильно управление памяти в С++/С коде является неправильным использвоанием этих языков аппрори и как аргумент не рассматривается.
Вы тут сами себя опровергаете. Ну в том смысле, что по аналогии я могу сказать, что неправильная работа с GC не рассматривается и входит в знание языка.
Пойнт в том, что в случае с GC сделать неправильно гораздо, гораздо сложнее.
>> можно продолжать и продолжать
Отлично, продолжите.
>>Qt — это С++ фреймворк чистой воды, как он может не быть C++
э-э-э. в вики написано, что дляя компиляции qt шного кода, его нужно обработать неким Meta Object Compiler'ом.
Если это так — то можно сказать, что например Haskell = С.
э-э-э. в вики написано, что дляя компиляции qt шного кода, его нужно обработать неким Meta Object Compiler'ом.
Если это так — то можно сказать, что например Haskell = С.
Однако, фраза из топика: «А так как я в своё время перелез с C++ на C#» как бы намекает, что и такое сравнение будет. Я, честно говоря, подумал, что вот сейчас меня наконец убедят перелезть на «упрявляемый» язык. Но нет, только ещё раз подтвердили, что такие языки эффективнее интерпретируемых, но медленне «родных», причём в тяжёлых случаях и то и другое — на порядок.
Qt != C++ только на тех платформах, где его нет и нельзя собрать.
Qt != C++ только на тех платформах, где его нет и нельзя собрать.
>Qt != C++ только на тех платформах, где его нет и нельзя собрать.
Такие есть? Оо
Такие есть? Оо
Рихтер намекает, что в некоторых случаях JIT-код может быть эфективнее родного, за счет большего знания конкретной среды исполнения.
Грубый пример навскидку:
if (Environment.ProcessorCount > 1)
{
…
}
на однопроцессорной машине будет вообще отсечен компилятором. Не говоря уже о знании о всяческих наборах экзотических процессорных команд и тд.
Грубый пример навскидку:
if (Environment.ProcessorCount > 1)
{
…
}
на однопроцессорной машине будет вообще отсечен компилятором. Не говоря уже о знании о всяческих наборах экзотических процессорных команд и тд.
Прямо справочник для холиварщиков.
+1.
Нет объективности, сплошная реклама.
Если уж развеивать мифы, то можно было бы и недостатки описать.
Нет объективности, сплошная реклама.
Если уж развеивать мифы, то можно было бы и недостатки описать.
А зачем вам недостатки? Все опровергли и теперь спорить не чем?:)
Меня не интересует .net и clr на столько. Но ваша статья не пахнет объективностью.
Конечно, вас поддержат любители MS в общем и тем более любители C#, но ваша статья явно не тянет на «развеивателя мифов». Она тянет на рекламу.
Впрочем, вы явно признаете, что вы лишь встаете на одну из сторон этого холивара:
> Мне захотелось исправить эту ситуацию, и выступить с одной из сторон.
Т.е. вы честно признаете что ваш пост ни что иное, как очередной ответный ход этом холиваре.
Конечно, вас поддержат любители MS в общем и тем более любители C#, но ваша статья явно не тянет на «развеивателя мифов». Она тянет на рекламу.
Впрочем, вы явно признаете, что вы лишь встаете на одну из сторон этого холивара:
> Мне захотелось исправить эту ситуацию, и выступить с одной из сторон.
Т.е. вы честно признаете что ваш пост ни что иное, как очередной ответный ход этом холиваре.
итак, начнем новый раунд холиваров))))
мое имхо:
1. C# — самое лучшее из того, что я пробовал, но опять же весь веб только под винду, и не надо мне про моно говорить, пробовали, все не то
2. высокоскоростные куски с максимальной оптимизацией все же лучше писать на С++ (была у меня задача по обработке гигабайтов текстовых данных — GC просто умирал, хотя может не так готовил, все решилось написанием программы на старом добром C++)
в общем, универсального ничего нет, ЯП и платформа выбирается под задачу
мое имхо:
1. C# — самое лучшее из того, что я пробовал, но опять же весь веб только под винду, и не надо мне про моно говорить, пробовали, все не то
2. высокоскоростные куски с максимальной оптимизацией все же лучше писать на С++ (была у меня задача по обработке гигабайтов текстовых данных — GC просто умирал, хотя может не так готовил, все решилось написанием программы на старом добром C++)
в общем, универсального ничего нет, ЯП и платформа выбирается под задачу
Не не не, я не хочу холиваров. Давайте оппонировать не ИМХОм, а фактами. Я свои привел )
В чем были проблемы с mono?
самый обычный Hello World, который я за минуту слепил в студии, на Mono отказывался запускаться
пробовал всяко, все равно вылазила ошибка
PS: все это было во времена 1-го дотнета, 2-й только-только появился, как сейчас — хз, но не думаю, что 100% совместимость
пробовал всяко, все равно вылазила ошибка
PS: все это было во времена 1-го дотнета, 2-й только-только появился, как сейчас — хз, но не думаю, что 100% совместимость
Hello World, я надеюсь, с тех пор заработал :)
Нет, ну это не серьезно, я думал у вас много опыта и ожидал рассказ об «особенностях» работы mono с asp, основываясь на этом высказывании:
а оказалось, что это было давно не правда. У самого home pet проект (uniquation) разрабаьывается под windows, деплоиться под mono, в том числе используется asp.net mvc 2 (galois/wiki) и проблем совместимости не было.
… весь веб только под винду, и не надо мне про моно говорить, пробовали, все не то
а оказалось, что это было давно не правда. У самого home pet проект (uniquation) разрабаьывается под windows, деплоиться под mono, в том числе используется asp.net mvc 2 (galois/wiki) и проблем совместимости не было.
2. «старом добром С++»
Так Вы С++ программист со стажем. А тут аргументы для холиворящих детей…
>>> в общем, универсального ничего нет, ЯП и платформа выбирается под задачу
надо в универах, а также всех учебниках для начинающих программистов это просто вдалбливать
Так Вы С++ программист со стажем. А тут аргументы для холиворящих детей…
>>> в общем, универсального ничего нет, ЯП и платформа выбирается под задачу
надо в универах, а также всех учебниках для начинающих программистов это просто вдалбливать
на чем я только не писал))))
по большей части — это С++ и С# для декстопных приложений, было немного Delphi и специализированных языков
сейчас по большей части веб на PHP + всякие фреймворки, постепенно перехожу на Python с Django
PS: лет через 10 с таким разбросом я буду программировать микроконтроллеры для роботов)))
по большей части — это С++ и С# для декстопных приложений, было немного Delphi и специализированных языков
сейчас по большей части веб на PHP + всякие фреймворки, постепенно перехожу на Python с Django
PS: лет через 10 с таким разбросом я буду программировать микроконтроллеры для роботов)))
Кстати, мне вот тоже довелось писать дата-майнер для 150 гигабайт w3c логов (просто space separated values). И к моему большому удивлению уже на парсинге файла C++ оказался в 1.5-2 раза медленнее шарпа. Да, я конечно мог реализовать собственный класс value-type строк с референсами на сами данные, хранящиеся отдельно, мог написать собственный аллокатор — мог много чего. Вместо этого я просто сделал все на шарпе.
В большинстве случаев он медленнее и жрет больше памяти, но та же Visual Studio работает очень шустро, да и PowerShell который я довольно интенсивно использую для всякого скриптинга и автоматизации оказался потрясающей штукой.
В большинстве случаев он медленнее и жрет больше памяти, но та же Visual Studio работает очень шустро, да и PowerShell который я довольно интенсивно использую для всякого скриптинга и автоматизации оказался потрясающей штукой.
очень странно, что же так тормозило в С++?
примерный алгоритм словами можете описать?
примерный алгоритм словами можете описать?
readline из стрима, потом разбиение на столбцы (кажется сначала regex итератором пользовался, потом переделал в посимвольное сканирование c_str() ). Я знаю где оно тормозило и знаю почему — это аллокации миллионов строк и копирование их туда сюда. Я ж говорю, естественно, это все можно было поправить, если бы это было так существенно. НО!
На шарпе полностью аналогичный код — без оптимизаций и заката солнца вручную — работал быстрее.
Если приложить максимальные усилия по оптимизации, очевидно, что из плюсов можно будет выжать больше.
На шарпе полностью аналогичный код — без оптимизаций и заката солнца вручную — работал быстрее.
Если приложить максимальные усилия по оптимизации, очевидно, что из плюсов можно будет выжать больше.
>Я знаю где оно тормозило и знаю почему — это аллокации миллионов строк и копирование их туда сюда
А вот если бы использовали implicity shared строки, то не пришлось бы копировать лишнее.
А вот если бы использовали implicity shared строки, то не пришлось бы копировать лишнее.
вы описали алгоритм работы в C#, насколько я понимаю,
а С++ что тормозило? C# меня не интересует
а С++ что тормозило? C# меня не интересует
Неявное разделение спасло бы отца русской демократии. Вообще на плюсах при некотором джедаизме можно сделать более быструю реализацию, чем на шарпах.
хм, как-то странно все это…
ну а если выделить достаточно большой буфер (например 10Мб) под обработку входного потока символов, а затем результаты сразу скидывать в файл, причем обязательно включить flush для файлов, чтобы не было тормозов при файловых операциях?
а миллионы аллокаций на С++ — тут на ум приходит только неумелое использование STL, когда строки используются в виде объекта string, тогда при каждом присвоении действительно будет новая аллокация
в любом случае, без конкретного исходного кода на С++ это все мои домыслы))
PS: ну не понимаю я как может код на С++ работать медленнее, чем на C#))
ну а если выделить достаточно большой буфер (например 10Мб) под обработку входного потока символов, а затем результаты сразу скидывать в файл, причем обязательно включить flush для файлов, чтобы не было тормозов при файловых операциях?
а миллионы аллокаций на С++ — тут на ум приходит только неумелое использование STL, когда строки используются в виде объекта string, тогда при каждом присвоении действительно будет новая аллокация
в любом случае, без конкретного исходного кода на С++ это все мои домыслы))
PS: ну не понимаю я как может код на С++ работать медленнее, чем на C#))
Вот поэтому-то и нет большого смысла сравнивать С++ и С# — ожидая результат «С++ быстрее С# anyway», мало толку искать этот ответ:
— если по результатам побеждает С++, публика кричит «воооот, а мы говорили же!», и на результаты не смотрит в принципе, даже если у С++ опережение в 2-5%.
— если по результатам побеждает С#, начинаются обвинения автора в том, что он не умеет писать на С++/подтасовал данные/С#-программу оптимизировал, а С++ нет/не знает хороших библиотек (нужное подчеркнуть) и уж точно С++программу можно было бы сделать быстрее :) Конечно, можно — в С++ теоретически больше контроль над тем, что ты делаешь. Но в С++ это — можно сделать, потратив дополнительно ресурсы — время или деньги на действительно хорошего С++программиста, а в С# — напедалил и готово.
— если по результатам побеждает С++, публика кричит «воооот, а мы говорили же!», и на результаты не смотрит в принципе, даже если у С++ опережение в 2-5%.
— если по результатам побеждает С#, начинаются обвинения автора в том, что он не умеет писать на С++/подтасовал данные/С#-программу оптимизировал, а С++ нет/не знает хороших библиотек (нужное подчеркнуть) и уж точно С++программу можно было бы сделать быстрее :) Конечно, можно — в С++ теоретически больше контроль над тем, что ты делаешь. Но в С++ это — можно сделать, потратив дополнительно ресурсы — время или деньги на действительно хорошего С++программиста, а в С# — напедалил и готово.
>И к моему большому удивлению уже на парсинге файла C++ оказался в 1.5-2 раза медленнее шарпа.
А я на шарпах могу написать так, что тормозить будет в 10 раз больше, чем на Питоне.
А я на шарпах могу написать так, что тормозить будет в 10 раз больше, чем на Питоне.
#. Так, алоэ, я кое-что вспомнил. О какой кросcплатформенности речь, когда чтобы запустить под Mono, мне надо всё перекомпилировать. Это же как в старом добром С, чем лучше-то?!Тут проблема скорее не в необходимости перекомпиляции, а в неполной поддержке Mono некоторых функций, например, нет VirtualMode у DataGridView.
Очередная глупость. Я не знаю, кто вам сказал, но в целом полностью управляемое CLR-приложение, скомпилированное под Windows, НЕ НУЖНО ПЕРЕКОМПИЛИРОВАТЬ. Можно ПРОСТО перенести на Linux с установленным Mono, скомандовать mono myapp.exe, и оно запустится. И наоборот тоже работает. Я проверял.
Ещё поговаривают, что WPF для моно можно не ждать.
>> At this point, no group in the Mono project has plans to implement Windows Presentation Foundation APIs as part of the project.
www.mono-project.com/WPF
Реально же, нестоит загадывать, еще полгода тому назад Мигель говорил что не будет брать IronPhyton и IronRuby. А теперь взял. Я больше волнуюсь что Майкры на WPF забьют ;).
www.mono-project.com/WPF
Реально же, нестоит загадывать, еще полгода тому назад Мигель говорил что не будет брать IronPhyton и IronRuby. А теперь взял. Я больше волнуюсь что Майкры на WPF забьют ;).
NET-приложения ужасно долго запускаются (на порядок дольше родного win-кода). Чтобы стало нормально работать, их надо еще и заранее откомпилировать. Скачал обновление? Будь добр подожди 5 минут, пока приложение повторно откомпилируется и поместится в GAC.
Это такая утонченная шутка?
Evernote — большое и популярное приложение.
Версия 3.5 написана на .NET, WPF.
Версия 4.0 написана на C++.
Цитата ( habrahabr.ru/company/evernote/blog/106994/ ):
В ходе тестирования с аппаратным обеспечением мы установили, что Evernote 4 запускается в пять раз быстрее и использует в два раза меньше памяти, чем Evernote 3.5.
Версия 3.5 написана на .NET, WPF.
Версия 4.0 написана на C++.
Цитата ( habrahabr.ru/company/evernote/blog/106994/ ):
В ходе тестирования с аппаратным обеспечением мы установили, что Evernote 4 запускается в пять раз быстрее и использует в два раза меньше памяти, чем Evernote 3.5.
Visual Studio 2008 нативный загрузчик, части написаны на .NET вин формах.
Visual Studio 2010 все менеджед, WPF.
Скорость увеличилась. Я не думаю что Evernote это показатель.
Но собно, меня больше волнует ваши утверждения «их надо еще и заранее откомпилировать» и «пока приложение повторно откомпилируется и поместится в GAC». Первое делается разработчиком, и собно процес очень быстрый. А второе просто или глуопсть или я не распознал сарказм.
Visual Studio 2010 все менеджед, WPF.
Скорость увеличилась. Я не думаю что Evernote это показатель.
Но собно, меня больше волнует ваши утверждения «их надо еще и заранее откомпилировать» и «пока приложение повторно откомпилируется и поместится в GAC». Первое делается разработчиком, и собно процес очень быстрый. А второе просто или глуопсть или я не распознал сарказм.
Под «поместить в GAC» подразумевалась сборка всех модулей и их предварительная компиляция в нативный код с помощью утилиты NGEN (где эта сборка будет лежать — не важно — в GAC или в другом месте). Как раз благодаря этому можно значительно ускорить загрузку net-приложений. Даже в той же самой Visual Studio при добавлении, изменении или удалении компонентов это делается.
>> Под «поместить в GAC» подразумевалась сборка всех модулей и их предварительная
>> компиляция в нативный код с помощью утилиты NGEN (где эта сборка будет лежать —
>> не важно — в GAC или в другом месте).
Я не знаю ниодного приложения которое бы этим сейчас занималось, когдато давно SharpDevelop этим балывался, но от этого отказались, так как выхлопа практически нет.
>> Как раз благодаря этому можно значительно ускорить загрузку net-приложений.
Еще со второй версии .NET появилась возможность делать это отложенно. Простите за цитату из МСДН.
>> Actions can be deferred for execution by a service that uses idle time on the computer to generate and install images.
msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx
>> Даже в той же самой Visual Studio при добавлении, изменении или удалении компонентов это делается.
Про какие компоненты вы говорите? Хотя я уже сейчас могу сказать, кто какие бы вы не имели компоненты ввиду, Visual Studio ничего не компилит и никуда не ложит. Ну или давайте прув какой то, мож я чегото не знаю.
>> компиляция в нативный код с помощью утилиты NGEN (где эта сборка будет лежать —
>> не важно — в GAC или в другом месте).
Я не знаю ниодного приложения которое бы этим сейчас занималось, когдато давно SharpDevelop этим балывался, но от этого отказались, так как выхлопа практически нет.
>> Как раз благодаря этому можно значительно ускорить загрузку net-приложений.
Еще со второй версии .NET появилась возможность делать это отложенно. Простите за цитату из МСДН.
>> Actions can be deferred for execution by a service that uses idle time on the computer to generate and install images.
msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx
>> Даже в той же самой Visual Studio при добавлении, изменении или удалении компонентов это делается.
Про какие компоненты вы говорите? Хотя я уже сейчас могу сказать, кто какие бы вы не имели компоненты ввиду, Visual Studio ничего не компилит и никуда не ложит. Ну или давайте прув какой то, мож я чегото не знаю.
Любые, которые что-либо встраивают в оболочку IDE (например, компоненты и утилиты от DevExpress). Во время установки или обновления можно запустить Process Explorer и посмотреть, как вызывается ngen-сервис для компиляции (как раз тот самый, из MSDN, который «запускается отложенно во время простоя Windows»).
Кстати, если вдруг у вас на компьютере установлено много «больших» NET-приложений (Visual Studio, MS SQL Server со своими утилитами и т.п.) и включен такой сервис оптимизации — готовтесь к тому, что размер системной папки будет расти день ото дня (и когда-нибудь отъест от нескольких сотен, до 1-2 Гб места на диске).
Кстати, если вдруг у вас на компьютере установлено много «больших» NET-приложений (Visual Studio, MS SQL Server со своими утилитами и т.п.) и включен такой сервис оптимизации — готовтесь к тому, что размер системной папки будет расти день ото дня (и когда-нибудь отъест от нескольких сотен, до 1-2 Гб места на диске).
Мы ходим по кругу, я вам говорю что никто ничего неждет. Намекаю на сервис. И потом вы таки делаете открытие что «вызывается ngen-сервис для компиляции». Тоесть с «будь добр подожди 5 минут, пока приложение повторно откомпилируется и поместится в GAC» вы уже не согласны? Или тогда скажите когда именно вы ждете эти 5 минут.
Вот мне, как разработчику, приходится частенько ждать, пока нужные инструменты и программы выполнят нужные оптимизации и будут готовы после очередного обновления.
Хорошо, раз непонятно, то вот объяснение по пальцам (подробнее просто некуда)…
У .NET есть проблемы с холодным стартом. При первом запуске какого-либо функционала, этот код необходимо откомпилировать в родной для процессора. Для пользователя это выливается в долгий запуск и задержках (лагах) при работе с программой.
Если хочется, чтобы все сразу и быстро запускалось, надо ЗАРАНЕЕ откомпилировать весь код приложения. Это занимает ВРЕМЯ, иногда довольно много времени. Предварительная компиляция делается как автоматически самой системой при ее простое, так и вызывается вручную при необходимости.
Чтобы пользователи не видели всю сущность NET и их проблемы с медленным запуском, некоторые разработчики ЗАРАНЕЕ компилируют свои приложения, например, при их установки или обновлении (Visual Studio, dbForge for MySQL и т.п.).
Обычно приложения обновляются при запуске или через соответсвующую кнопку. А это значит, что после обновления пользователь хочет продолжить работать с программой как ни в чем не бывало. Что в свою очередь приводит к необходимости повторной компиляции кода, иначе — «привет, тормоза».
Хорошо, раз непонятно, то вот объяснение по пальцам (подробнее просто некуда)…
У .NET есть проблемы с холодным стартом. При первом запуске какого-либо функционала, этот код необходимо откомпилировать в родной для процессора. Для пользователя это выливается в долгий запуск и задержках (лагах) при работе с программой.
Если хочется, чтобы все сразу и быстро запускалось, надо ЗАРАНЕЕ откомпилировать весь код приложения. Это занимает ВРЕМЯ, иногда довольно много времени. Предварительная компиляция делается как автоматически самой системой при ее простое, так и вызывается вручную при необходимости.
Чтобы пользователи не видели всю сущность NET и их проблемы с медленным запуском, некоторые разработчики ЗАРАНЕЕ компилируют свои приложения, например, при их установки или обновлении (Visual Studio, dbForge for MySQL и т.п.).
Обычно приложения обновляются при запуске или через соответсвующую кнопку. А это значит, что после обновления пользователь хочет продолжить работать с программой как ни в чем не бывало. Что в свою очередь приводит к необходимости повторной компиляции кода, иначе — «привет, тормоза».
Позвольте не согласиться. Я ставил 2010 студию на нетбук, работало ощутимо медленее, чем 2008 студия. Запускалась точно в 1.5 раза дольше.
Вы издеваетесь? Пример: солюшн С++/C#, ~350 проектов, открытие:
Visual Studio 2003 SP1 — меньше минуты
Visual Studio 2008 SP1 — 1,5 минуты
Visual Studio 2010 — 10 минут
Увеличилась?
Visual Studio 2003 SP1 — меньше минуты
Visual Studio 2008 SP1 — 1,5 минуты
Visual Studio 2010 — 10 минут
Увеличилась?
Ну не все тут в студии операционки разрабатывают :)
Да спецом написал, чтобы вас позлить. ~350 это круто. Что вы пишете?
Большое сереверное решение, подробности не особо важны. Я хотел обратить внимание на пропорцию, а не абсолютные величины.
В этом случае я хочу обратить ваше внимание, что система загрузки проектов существенно не менялась между 2008 и 2010. Уместней было бы сравнивать запуск студии до старотового екрана. Это показывало насколько новый WPF шелл, быстрее/медленнее старого анменджед + WinForms.
В любом случае, я вполне допускаю что именно на моем компе, с моими конфигурациями плагинов, картина отличается, от вашей.
В любом случае, я вполне допускаю что именно на моем компе, с моими конфигурациями плагинов, картина отличается, от вашей.
Ага, а открытие .sln-файла в блокноте вообще 1 секунда!
Это Intellisense парсит код. Чем новее студия, тем мощнее Intellisense, и тем дольше он отрабатывает.
WPF/WinForms тут не причем.
Это Intellisense парсит код. Чем новее студия, тем мощнее Intellisense, и тем дольше он отрабатывает.
WPF/WinForms тут не причем.
Открывали один и тот же солюшен или с разницей в 7 лет кодинга N программистами?
Насчет времени запуска — емнип это косяк именно WPF, который поднимает там всю графическую подсистему. У меня это выливалось в 4-секундный cold start для микроскопического приложения. Те программы, написаные на WPF сейчас (например мой TypograFix) проявляют сейчас те же характеристики.
Но вот что до WinForms, то таких проблем нет — хотя есть коррелирующая проблема в том, что мы подвязываем толстые библиотеки а-ля DevExpress по 10Мб, которые тоже отбирают время на старте. Но не 4 секунды, значительно меньше.
Но вот что до WinForms, то таких проблем нет — хотя есть коррелирующая проблема в том, что мы подвязываем толстые библиотеки а-ля DevExpress по 10Мб, которые тоже отбирают время на старте. Но не 4 секунды, значительно меньше.
мне тоже показалось что ребята не стали заморачиваться с оптимизацией WPF.
А оптимизировать там можно было много чего.
А может быть готовятся к *nix версии? а там C++ проще портировать.
А оптимизировать там можно было много чего.
А может быть готовятся к *nix версии? а там C++ проще портировать.
Некоторые приложения грузятся действительно долго. Но чаще всего проблема в неоптимальной загрузке сборок.
А что такое «родной win-код»?
Бред какойто о_О
+ хотелось бы отметить, что первый запуск конкретно этого приложения и первый запуск любого .NET приложения после перезагрузки системы немного разные вещи. Второе делается дольше, но это только в целях уменьшения времени запуска винды и это исправимо.
+ хотелось бы отметить, что первый запуск конкретно этого приложения и первый запуск любого .NET приложения после перезагрузки системы немного разные вещи. Второе делается дольше, но это только в целях уменьшения времени запуска винды и это исправимо.
Правда, здесь вступает в ход связывание с библиотеками. Это как gems в Ruby — если этот конкретный gem использует нативные библиотеки, то вам нужно установить эти самые нативные библиотеки.
Насколько я понимаю, не кроссплатформенность многих библиотек является слабым местом .NET по сравнению с альтернативными технологиями. Так ли это?
И да, и нет.
С точки зрения серверного разработчика, практически всё, что мне нужно, есть как в nix, так и в win — управляемое или нет, не суть важно. Даже и не вспомню, чего мне не хватает. Из того, что нет в nix, это, наверное, WMI.
С точки зрения клиентской части — да, здесь ситуация похуже: WinForms еще недостаточно полностью портированы в Mono, поэтому тут могут ждать сюрпризы. Плюс, некроссплатформенны, как правило, сторонние коммерческие компоненты, зачастую визуальные. И их не удаётся завести под Mono. Такое отношение компаний, к сожалению, становится проблемой самого .NET, а не компаний — авторов компонент.
Но опять же, насчет UI — есть binds к стандартным GTK# и Tk, которые одинаково хорошо работают и там, и там. Пример такого UI: MonoDevelop
С точки зрения серверного разработчика, практически всё, что мне нужно, есть как в nix, так и в win — управляемое или нет, не суть важно. Даже и не вспомню, чего мне не хватает. Из того, что нет в nix, это, наверное, WMI.
С точки зрения клиентской части — да, здесь ситуация похуже: WinForms еще недостаточно полностью портированы в Mono, поэтому тут могут ждать сюрпризы. Плюс, некроссплатформенны, как правило, сторонние коммерческие компоненты, зачастую визуальные. И их не удаётся завести под Mono. Такое отношение компаний, к сожалению, становится проблемой самого .NET, а не компаний — авторов компонент.
Но опять же, насчет UI — есть binds к стандартным GTK# и Tk, которые одинаково хорошо работают и там, и там. Пример такого UI: MonoDevelop
Это как неуловимый Джо. Удостоверится что библиотека кросплатформена очень легко, но пока интерес небольшой, это делают редко. Хотя в последнее время ситуация улучшается. Этому всему очень мешает активное анти-МС лобби в линуксовой комунити. Под раздачу попадает и Моно. Если бы по идеологическим причинам люди не противились Моно, на нем бы больше писали и соотвевенно больше бы библиотек верифицировалось.
или ранее известных: Delphi, Ada, Lisp, VB, php, в качестве back-end использующих CLR.
хмм, допустим у меня код на php, где он будет работать — под CLR или под нативным интерпретатором? (btw trollface заключается в том что php можно компилировать)
берёшь phalanger и запускаешь свой любимый php под CLR, и пользушься всеми фишечками .netовских библиотек, и делаешь pinvoke, и
Всё зависит от того, с какой стороны гриба вы откусите что вы используете.
Например, Phalanger в режиме pure полностью компилирует php-приложение в MSIL, который исполняется CLRом так же, как если бы он был написан на C# или чем-то еще. Это как раз тот случай, что я имел в виду.
Другой вариант — Phalanger в режиме legaсy работает как классический интерпретатор php, написанный на CLR: транслирует php в родные байт-коды php, и их исполняет. Но этот случай нам не интересен — ничего необычного
Например, Phalanger в режиме pure полностью компилирует php-приложение в MSIL, который исполняется CLRом так же, как если бы он был написан на C# или чем-то еще. Это как раз тот случай, что я имел в виду.
Другой вариант — Phalanger в режиме legaсy работает как классический интерпретатор php, написанный на CLR: транслирует php в родные байт-коды php, и их исполняет. Но этот случай нам не интересен — ничего необычного
Ну что сказать, весьма эпатажный пост но абсолютно не достигнет своей целевой аудитории. Причина в том, что языки программирования это как религии, у людей минимум рационализма, но зато огромное желание покричать. Приплюсуйте к этому ущемленное эго и обиду на всех привсех и вы поймете, что в принципе ничего уже не исправить.
И тут, вдруг все джава-питоно-руби-др. фанаты воскликнули: «что же вы сразу не сказали все это!» и перешли на c#(.net) :)
Шутки шутками, а у меня вот возникло острое желание поставить винду и студию. Хотя дотнета уже три года в руки не брал :-)
Ну так, вроде бы, джава как раз не особо отличается во всех описанных аспектах :) Почти везде в статье можно вместо C#/CLR/… подставить Java/JVM/…
Всякие TraceMonkey, LuaJIT, YARV как раз примеры для последней классификации. Это означает, что переход на другую платформу сходной архитектуры заведомо не сделает приложение медленнее.
Да ну. Переход с LuaJIT на YARV не сделает приложение медленнее? Ещё как сделает. Так что одна архитектура в таком сравнении мало о чём говорит.
#. Программы на CLR жрут очень много памяти. Прям вааще всё жрут, ничего не оставляют…
Хм. Сравнимое нагруженное Ruby-on-Rails-приложение на сервере кушает 100-150МБ RAM, примерно столько же, сколько и ASP.NET CLR сайт. Тут нет большой разницы.
Сравнивать с Ruby весело, да. А со сравнимым приложением на C++?
Уже сейчас есть параметрический полиморфизм (это когда Vector)
А я думал, что параметрический полиморфизм это нечто другое :)
Нет. Все управляемые приложения .NET можно распространять по модели deploy-by-copy — скопируй в нужную папку и запускай оттуда.
Все? Visual Studio написана на .Net, попробуйте её deploy-by-copy :) Конечно, писать такие приложения можно.
>> Переход с LuaJIT на YARV не сделает приложение медленнее? Ещё как сделает
Мы же здесь про переход ZZZ -> CLR. Наибольшие опасения у людей вызывает то, что при использовании CLR их приложения, ранее написанные на Ruby/Php/Python и других скриптовых языках, станут на порядок медленнее. Не станут, это факт.
>> Сравнивать с Ruby весело, да. А со сравнимым приложением на C++?
С++ неуправляемое приложение, сравнивать особо смысла нет :)
Если хотите — давайте попробуем. Но мне потребуется ваша помощь. Электронный web-магазин на С# кушает порядка 45-60МБ при ~20-50пользователях. Сколько будет «есть» такой же на С++?
>> я думал, что параметрический полиморфизм это нечто другое
Хабрапарсер сожрал :( Там была параметризация типами. Надо исправить
>> Visual Studio написана на .Net
Visual Studio могла бы быть deploy-on-copy, если бы не интегрировалась тесно с окружением: My documents, COM Infrastructure, отладчики и т.д. Это проблемы VS IDE, а не CLR.
Мы же здесь про переход ZZZ -> CLR. Наибольшие опасения у людей вызывает то, что при использовании CLR их приложения, ранее написанные на Ruby/Php/Python и других скриптовых языках, станут на порядок медленнее. Не станут, это факт.
>> Сравнивать с Ruby весело, да. А со сравнимым приложением на C++?
С++ неуправляемое приложение, сравнивать особо смысла нет :)
Если хотите — давайте попробуем. Но мне потребуется ваша помощь. Электронный web-магазин на С# кушает порядка 45-60МБ при ~20-50пользователях. Сколько будет «есть» такой же на С++?
>> я думал, что параметрический полиморфизм это нечто другое
Хабрапарсер сожрал :( Там была параметризация типами. Надо исправить
>> Visual Studio написана на .Net
Visual Studio могла бы быть deploy-on-copy, если бы не интегрировалась тесно с окружением: My documents, COM Infrastructure, отладчики и т.д. Это проблемы VS IDE, а не CLR.
Мы же здесь про переход ZZZ -> CLR. Наибольшие опасения у людей вызывает то, что при использовании CLR их приложения, ранее написанные на Ruby/Php/Python и других скриптовых языках, станут на порядок медленнее. Не станут, это факт.
Людей, которые этого опасались при переходе с C/C++, я видел много. А при переходе с Ruby/PHP/Python — даже не припомню. Но в любом случае, схожесть архитектуры о скорости ничего полезного не говорит. (Разница в архитектуре — может.)
С++ неуправляемое приложение, сравнивать особо смысла нет :)
Как раз наоборот, потому что утверждения типа «Java/C#/и т.д. жрут кучу памяти» я слышал опять-таки в 99% случаев от C++-ников.
Visual Studio могла бы быть deploy-on-copy, если бы не интегрировалась тесно с окружением
Утверждение было про "все управляемые приложения", что заведомо неверно.
Уныло. Придумываем тупые аргументы и наставническим тоном опровергаем их. В таком стиле можно написать про любую технологию. К тому же некоторые опровержения недалеко ушли по тупости от аргументов.
>>Программы на CLR жрут очень много памяти?
А руби тоже много жрёт, так-то! (странный аргумент, почему бы не сравнить с C++, вместо руби?)
>>Специальный компилятор JIT постепенно преобразует байткод программы в нативный код, примерно такой же, который выдаёт компилятор C++.
Я какбэ могу написать кривой компилятор, который тоже будет выдавать нативный код примерно такой же, как и нормальные компиляторы. Вот только нативность не гарантирует скорость выполнения.
>>в C# наиболее полно доступны все возможности CLR, но никто не заставляет пользоваться именно им
Перефразирую: писать на шарпе не обязательно, но если будешь писать на других языках — будешь чувствовать себя ущербным, и рано или поздно всё равно перейдешь на шарп.
>> Есть SharpDevelop… есть MonoDevelop… Есть плагины к Eclipse…
Т.е. MSVS не нужна? Или опять-таки будешь чувствовать себя ущербным и рано или поздно перейдешь на студию?
>>на нем достаточно просто писать… управляемая среда позволяет исключить целый класс ошибок… первоклассный IntelliSense… решения на C#/CLR обходятся не так дорого, как в Java.
Great, amazing, wonderful, remarkable, better and better and better.
>>Программы на CLR жрут очень много памяти?
А руби тоже много жрёт, так-то! (странный аргумент, почему бы не сравнить с C++, вместо руби?)
>>Специальный компилятор JIT постепенно преобразует байткод программы в нативный код, примерно такой же, который выдаёт компилятор C++.
Я какбэ могу написать кривой компилятор, который тоже будет выдавать нативный код примерно такой же, как и нормальные компиляторы. Вот только нативность не гарантирует скорость выполнения.
>>в C# наиболее полно доступны все возможности CLR, но никто не заставляет пользоваться именно им
Перефразирую: писать на шарпе не обязательно, но если будешь писать на других языках — будешь чувствовать себя ущербным, и рано или поздно всё равно перейдешь на шарп.
>> Есть SharpDevelop… есть MonoDevelop… Есть плагины к Eclipse…
Т.е. MSVS не нужна? Или опять-таки будешь чувствовать себя ущербным и рано или поздно перейдешь на студию?
>>на нем достаточно просто писать… управляемая среда позволяет исключить целый класс ошибок… первоклассный IntelliSense… решения на C#/CLR обходятся не так дорого, как в Java.
Great, amazing, wonderful, remarkable, better and better and better.
Перефразирую: писать на шарпе не обязательно, но если будешь писать на других языках — будешь чувствовать себя ущербным, и рано или поздно всё равно перейдешь на шарп.
ИМХО это справедливо для языков, примерно изооморфных C#
А так, разные языки — разные возможности. Если, например, вам хочется pattern-matching, но неважен дизайнер форм с code-behind — то будете продолжать использовать F#.
Есть даже возможности CLR недоступные из C# но доступные из ILASM.
ИМХО это справедливо для языков, примерно изооморфных C#
А так, разные языки — разные возможности. Если, например, вам хочется pattern-matching, но неважен дизайнер форм с code-behind — то будете продолжать использовать F#.
Есть даже возможности CLR недоступные из C# но доступные из ILASM.
[irony]Заставлять моих пользователей качать и мучительно долго ставить 48 Mb фреймворка? Расскажите о преимуществах разработчикам 300-килобайтного uTorrent![/irony]
Фреймоворк побольше будет. А после его установки еще 2-3 раза устанавливать обновления безопасности и перезагружать компьютер.
.net compact edition весит примерно столько.
Я помню как я ставил paint.net где-то год назад. При установке он сразу предложил скачать .net 3.5 client profile. Ну молодец. Скачал и установил. А дальше через winupdate пришел sp1 для 3.5. Потребовал перезагрузку. После снова через winupdate пришли какие-то мелкие обновления. Опять перезагрузка. А потом еще раз пришли какие-то обновления.
это ответ на разоблачение какого мифа?
[sarcasm]Ваши пользователи до сих пор используют Win XP старее SP1? Расскажите об апгрейде суровым пользователям О 10ти-летней давности![/sarcasm]
;)
;)
Заставлять пользователей uTorrent качать 1ГБ Windows покупать за $150? Расскажите о преимуществах разработчикам GRUB
Не имеет отношения к этому мегахоливару, но в uTorrent'е забавный отжег имеется. Тот бинарник «инсталлятора», который скачивается по дефолт-кнопке с официального сайта и есть основной (и единственный) исполняемый файл. При его запуске верифицируется ключ в реестре и если uTorrent понимает что он не установлен — проводит операцию разворачивания самого себя та как нужно (угу, мастер установки в нем же).
Возможно многим известно, но меня этот факт недавно удивил.
Возможно многим известно, но меня этот факт недавно удивил.
Если серьёзно, переносимость кода достигается в том же C++ использованием, к примеру, wx или qt, а проблемы с памятью решаются чем-нибудь вроде boost:shared_ptr.
И реально выгоднее перейти на wx и boost, чем переключиться на C# и потерять всех тех клиентов, кто, зайдя на сайт продукта и увидев «требует скачиванияневедомой фигни .NET», закроют вкладку и пойдут искать аналог, который ничего не требует. А таких, как показывает практика, немало — пользователи вообще не любят устанавливать себе что-то, предназначения чего они не понимают. Им не объяснишь про преимущества управляемого кода и т.д. и т.п.
И реально выгоднее перейти на wx и boost, чем переключиться на C# и потерять всех тех клиентов, кто, зайдя на сайт продукта и увидев «требует скачивания
В корпоративном мире замечательно понимают расклад «либо фреймворк, либо в 2 раза больший бюджет».
И к конкурентам уходить бессмысленно, потому что стоимость разработки нативных приложений все равно выше, чем управляемых. Если только у них, конечно, нет огромного количества костылей, которые делают черную работу и избавляют от последствий безмозглости программиста.
И к конкурентам уходить бессмысленно, потому что стоимость разработки нативных приложений все равно выше, чем управляемых. Если только у них, конечно, нет огромного количества костылей, которые делают черную работу и избавляют от последствий безмозглости программиста.
неведомая фигня уже встроена в состав windows, если конечно у вас не икспишечка.
ыыы поржал, с каких это пор сайты с использованием Js требуют что то скачивать?:) вы бы хоть про технологию узнали, то что бекэнд сайта на jave,php,python или чем то еще, вас это каким образом заставляет скачивать jvm или интерпретатор php или python
Прочитав топик, у меня сложилось впечатление, что автор как бы говорит нам «Руби это круто, но шарп тоже ничего». Странно, как то.
Спор «JVM vs. CLR» уже не в моде чтоли?
Спор «JVM vs. CLR» уже не в моде чтоли?
1- тут обсуждение идет Мифы про C#, а не C# против 1 конкретного языка.
После последних приколов в мире Java в виде споров Oracle vs Google и тп
очень большая часть C# разработчиков взвыла, мол не дай боже java завалят. Без конкуренция любой продукт станет болотом. Так, что сейчас очень многие C# разработчики молятся на java, только бы ее не трогали, а лучше помогли в развитии.
Так, что обсуждать jvm vs clr -это гадить в огород хоть и конкурентов, но таких которые особо не страшны тк такие же как и мы, с другой стороны помогающие развитию.
После последних приколов в мире Java в виде споров Oracle vs Google и тп
очень большая часть C# разработчиков взвыла, мол не дай боже java завалят. Без конкуренция любой продукт станет болотом. Так, что сейчас очень многие C# разработчики молятся на java, только бы ее не трогали, а лучше помогли в развитии.
Так, что обсуждать jvm vs clr -это гадить в огород хоть и конкурентов, но таких которые особо не страшны тк такие же как и мы, с другой стороны помогающие развитию.
1- тут обсуждение идет Мифы про C#, а не C# против 1 конкретного языка.
С чего бы? Топик озаглавлен 'Мифы и заблуждения насчёт CLR и .NET'. Сравнивать CLR и JVM вполне корректно — и то, и то — виртуальные машины поддерживающие множество языков.
Так какой миф про CLR относительно JVM вы хотите чтобы автор развеял?
Если развеивать миф, о котором я знаю, что это миф — то для меня подобная информация будет бессмысленна. Про мифическую сущность остальных мифов, мне, очевидно, неизвестно. Следовательно и указать я на них не могу.
Ergo вы поставили либо бессмысленную, либо невозможную задачу.
Ergo вы поставили либо бессмысленную, либо невозможную задачу.
Если нема мифов то чего сравнивать? Я тогда не понимаю чего вы так хотите сравнивать CLR и JVM?
Вы плохо следите за дискуссией. Сравнивать их хотел leorik, на что SychevIgor приравнял JVM к «одному конкретному языку» (видимо, Java). На что я ему и возразил, что топик был о CLR, коммент leorik — о JVM, и что они вполне сравнимы.
После этого пришли вы, и приписали мне желание их сравнивать, какового желания я не испытывал ни в малейшей степени.
После этого пришли вы, и приписали мне желание их сравнивать, какового желания я не испытывал ни в малейшей степени.
Как я понимаю, то C#-пом можно быстро и легко разработать приложение для бизнеса. А потом, если всё сложиться успешно, можно переписывать на C++.
Т.е. для обычного бизнеса хватит и шарпа. Использовать бизнесу плюсы на начальном этапе это как пылесосить улицы: в принципе можно и результат лучше, но в начале очень не выгодно.
Т.е. для обычного бизнеса хватит и шарпа. Использовать бизнесу плюсы на начальном этапе это как пылесосить улицы: в принципе можно и результат лучше, но в начале очень не выгодно.
.NET сильно мешает имидж Microsoft, которая немало потрудилась для его создания. Представим на минутку, что .NET делает кто-то другой, или это вообще, это open source, была бы совсем другая история. В отношении ко всему, что делает MS много «идеологии»
С момента появления .Net и C# в частности, вопрос о крутизне Ruby, Php, Java, _____ (вписать по желанию) с повестки дня снят за неактуальность.
А учитывая то, какими темпами развивается C#, вопрос можно закрывать на ближайшие 10 лет.
Динамические языки — слишком динамические, чтобы их воспринимали серьезно, функциональные — слишком не от мира сего, нужен баланс, что в случае с C# был грамотно достигнут.
Дальше язык можно не искать, лучше писать прикладные библиотеки…
А учитывая то, какими темпами развивается C#, вопрос можно закрывать на ближайшие 10 лет.
Динамические языки — слишком динамические, чтобы их воспринимали серьезно, функциональные — слишком не от мира сего, нужен баланс, что в случае с C# был грамотно достигнут.
Дальше язык можно не искать, лучше писать прикладные библиотеки…
В чем-то согласен. Возможно стоит успокоиться насчет языков и поикать интересностей в библиотеках.
Тонко. А собственно почему можно снять за неактуальность? и главное — с ЧЬЕЙ повестки?
Да что вы?! Посмотрите на график внизу страницы, и осознайте, что в ближайшие 10 лет С# не выйдет за пределы 10 процентов поп популярности, если к тому времени вообще не пропадет.
Дело в том, что в упомянутом примере GCC (в случае с С++, например) делает огромное количество работы: парсинг и репарсинг текста программы, лексический, семантический и синтаксический анализ результатов парсинга, составление ее абстрактного дерева, распределение ресурсов и т.д.
В случае с JIT работы намного меньше — JIT компилирует из промежуточного представления, больше всего похожего на обычный ассемблер. В самом простом случае всё, что ему нужно сделать — распределить регистры и вычислить метки переходов.
Сравните скорость компиляции GCC/C++ и GAS (если вы в Linux), и вы поймете, насколько JITу проще.
В случае с JIT работы намного меньше — JIT компилирует из промежуточного представления, больше всего похожего на обычный ассемблер. В самом простом случае всё, что ему нужно сделать — распределить регистры и вычислить метки переходов.
Сравните скорость компиляции GCC/C++ и GAS (если вы в Linux), и вы поймете, насколько JITу проще.
Есть и минусы — отсутствие глобальной оптимизации кода, все методы становятся виртуализированными, т.е. вызов через таблицу поинтеров.
Только это уже убивает производительность любого вызова метода раза в 3 на современных процессорах, на старых вообще раз в 10 падала.
Но это проблемы всех jit-базированных технологий.
Только это уже убивает производительность любого вызова метода раза в 3 на современных процессорах, на старых вообще раз в 10 падала.
Но это проблемы всех jit-базированных технологий.
> самом простом случае всё, что ему нужно сделать — распределить регистры
Распределение регистров через раскраску графа — это NP задача и оптимального результата нельзя достигнуть за полномиальное время. Если вы считаете, что jit требуется выполнить примерно то же, что и gas — то вы глубоко заблуждаетесь.
Распределение регистров через раскраску графа — это NP задача и оптимального результата нельзя достигнуть за полномиальное время. Если вы считаете, что jit требуется выполнить примерно то же, что и gas — то вы глубоко заблуждаетесь.
>>… оптимального результата нельзя достигнуть…
Не оптимального, а наилучшего. Оптимальный достичь можно, но он не будет абсолютно лучшмм. Поэтому ищется не наилучший, а оптимальный по отношению к оценочной функции.
В случае с ARM-процессорами оценочная функция, например — минимальное число копирований между регистрами, сами регистры ортогональны и равнозначны. Так что какие графы, распределение регистров делается простым табличным способом. Это быстро.
Не оптимального, а наилучшего. Оптимальный достичь можно, но он не будет абсолютно лучшмм. Поэтому ищется не наилучший, а оптимальный по отношению к оценочной функции.
В случае с ARM-процессорами оценочная функция, например — минимальное число копирований между регистрами, сами регистры ортогональны и равнозначны. Так что какие графы, распределение регистров делается простым табличным способом. Это быстро.
ЛОЛШТО?
У вас там на ARMе что-ли количество регистров бесконечное? )))
А пацаны то уже несколько десятков лет пытаются регистры распределить хорошо, и не знают, что табличным способом всё делается.
Вы бы хоть прежде чем писать такое хотя бы уж статью в википедии про register allocation почитали…
У вас там на ARMе что-ли количество регистров бесконечное? )))
А пацаны то уже несколько десятков лет пытаются регистры распределить хорошо, и не знают, что табличным способом всё делается.
Вы бы хоть прежде чем писать такое хотя бы уж статью в википедии про register allocation почитали…
Хе-хе, я из ваших комментариев уже понял, что вы большой специалист по раскраске графов. И всё же я рекомендую вам иногда читать что-нибудь кроме Википедии. А лучше — самому заниматься практическим решением таких проблем. Потому что «распределить хорошо» — это расплывчатое теоретическое понятие. А вот распределить «удовлетворительно» — вполне нормально для практики.
А количество регистров в ARM можно посмотреть в той же Википедии. В самых простых RISC-машинах (типа AVR-контроллеров) их меньше 30 бывает редко. В той же Википедии написано, что еще существует стек ;) Как организовывать кадры стека на регистрах и наоборот, вытеснять регистры в стек, думаю, вы тоже должны знать.
Остальное по индукции
А количество регистров в ARM можно посмотреть в той же Википедии. В самых простых RISC-машинах (типа AVR-контроллеров) их меньше 30 бывает редко. В той же Википедии написано, что еще существует стек ;) Как организовывать кадры стека на регистрах и наоборот, вытеснять регистры в стек, думаю, вы тоже должны знать.
Остальное по индукции
Все просто,
1) jit происходит тока один раз для куска код, а в интерпритируемом языке каждый раз (упрощенно, в современных реализациях это не так).
2) Более того в том же .NET jit может проходить до запуска приложения, когда комп неиспользуется (упрощенно).
3) Ну и jit насамом то деле работает уже по байткоду (IL), тоесть парсинга тож нема.
1) jit происходит тока один раз для куска код, а в интерпритируемом языке каждый раз (упрощенно, в современных реализациях это не так).
2) Более того в том же .NET jit может проходить до запуска приложения, когда комп неиспользуется (упрощенно).
3) Ну и jit насамом то деле работает уже по байткоду (IL), тоесть парсинга тож нема.
Нет jit сейчас везде тулят, Гугуль для Хрома написали Javascript движек V8, там для кусоков кода (упрощенно) используется jit. Тоже самое сделали Майкры и Мозилла со своим Javascript движками. Быстрее всего java тоже юзает jit.
pyc это байткод полученный компиляцией из исходников, а не JIT из байткода в машинный код
vm без jit = сплошной интерпретатор. время на компиляцию = 0.
vm c jit = очень продвинутый интерпретатор с компиляцией на лету. время на компиляцию != 0. В итоге время испольнения байт-кода приблизительно должно быть одинаково.
без JIT:
1. запускаем программу (1 сек)
2. крутим цикл стотыщмильёнов раз (каждая итерация 0.001 сек)
…
общий рантайм: 100 000 001 сек (~3.16 лет)
c JIT:
1. запускаем программу (1 сек)
2. компилируем цикл (1000 сек)
3. крутим цикл стотыщмильёнов раз (каждая итерация 0.000001 сек)
…
общий рантайм: 101 001 сек (~28 часов)
в итоге выигрыш от jit зависит от соотношения времени на компиляцию кода к времени на выполнение этого кода.
Если в вашем коде нет циклов, то извините, как вы напишите код, который будет выполняться пару часов хотябы?
а если он выполняется 2 секунды(ну положим вы знаток ctrl+ ctrl+v или Thread.Sleep()) то а зачем вам вообще производительность то заоблачная?
Git компилятор генерирует код для конкретной аппаратной платформы из промежуточного кода и может использовать возможности железки, о которых разработчик мог не знать, следовательно разработчик на C++ либо должно был собрать 100 версий софта, либо что вероятнее собрать его под 386 процессора.
Можно ведь сделать и без git… на пример спользовать ngen, который собирет уже нативный код на машине. Так большие библиотеки делают примя во время установке. Тк после установки софта, мигрировать его уже вряд ли будут.
а если он выполняется 2 секунды(ну положим вы знаток ctrl+ ctrl+v или Thread.Sleep()) то а зачем вам вообще производительность то заоблачная?
Git компилятор генерирует код для конкретной аппаратной платформы из промежуточного кода и может использовать возможности железки, о которых разработчик мог не знать, следовательно разработчик на C++ либо должно был собрать 100 версий софта, либо что вероятнее собрать его под 386 процессора.
Можно ведь сделать и без git… на пример спользовать ngen, который собирет уже нативный код на машине. Так большие библиотеки делают примя во время установке. Тк после установки софта, мигрировать его уже вряд ли будут.
Не знаю как Вы это получили, но думаю в данном при сборке в Release компилятор бы вообще убрал к чертовой матери цикл, по причине отсутсвия в нем необходимости. Разве, что поставить атрибут запрещающий оптимизацию.
Не знаю как Вы это получили,
Из головы придумал, для иллюстрации принципа. Вы же не думаете, что я провел натурный экперимент длительностью в 3 года ради того комментария?
но думаю в данном при сборке в Release компилятор бы вообще убрал к чертовой матери цикл, по причине отсутсвия в нем необходимости.
А кто сказал, что цикл был пустым?
Да, компиляция на лету байт-кода в нативный занимает некоторое время. Но это компенсируется многими другими выгодами. Например, у компилятора JIT есть точные данные о процессоре, на котором будет исполнятся код, в отличие от компилятора gcc, который только знает, что там будет какой-то x86.
У компилятора JIT могут быть данные профилирования. Например, JS-компилятор Mozilla выявляет «горячие точки» в приложении, и оптимизирует их согласно собранным данным. Например, он может выявить что такой-то цикл всегда исполняется ровно 28 раз, и развернуть цикл.
У компилятора JIT могут быть данные профилирования. Например, JS-компилятор Mozilla выявляет «горячие точки» в приложении, и оптимизирует их согласно собранным данным. Например, он может выявить что такой-то цикл всегда исполняется ровно 28 раз, и развернуть цикл.
Интересно насколько крутой там провайлер. Если для gcc есть куча настроек для оптимизации (по разворачиванию циклов, по работе с плавающей точкой, поддержка всяких SSE4, 3DNOW и т.д.), что может предложить jit?
Вот SSE4 и 3dNow отличный пример. Настройки не нужны, jit-компилятор просто знает, есть они или нет.
Единственный известный мне компилятор (не только статический, а вообще, включая jit), который худо-бедно умеет векторизовать циклы на SSE — это intel C/C++/Fortran compiler.
Векторизация циклов — это такая нехилая по сложности и времени задача, для успешного выполнения которой в более-менее реальных случаях требуется alias analysis и глобальный анализ кода. Вы правда думаете, что jit может себе такое позволить? ;) Да там как бы удаление проверок выхода за границы массива (без чего векторизация не возможна) уже за счастье считается, а Вы тут на векторизацию замахнулись.
Например, jit в hotspot vm только недавно научился удалять проверки границ массивов в самых простых случаях.
Вот и получается, что на словах — «оптимизация под конкретный процессор», а на деле — хер с маслом, разве что скалярные вычисления на SSE делать, да какой-нибудь cmov заиспользовать.
Векторизация циклов — это такая нехилая по сложности и времени задача, для успешного выполнения которой в более-менее реальных случаях требуется alias analysis и глобальный анализ кода. Вы правда думаете, что jit может себе такое позволить? ;) Да там как бы удаление проверок выхода за границы массива (без чего векторизация не возможна) уже за счастье считается, а Вы тут на векторизацию замахнулись.
Например, jit в hotspot vm только недавно научился удалять проверки границ массивов в самых простых случаях.
Вот и получается, что на словах — «оптимизация под конкретный процессор», а на деле — хер с маслом, разве что скалярные вычисления на SSE делать, да какой-нибудь cmov заиспользовать.
Понравился вопрос-ответ про среды разработки для .NET. Один мой товарищ, пишет весьма серьезные вещи в текством редакторе FAR'a, а проекты собирает с помощью MS Build через батник. Так что тот факт, что писать на .NET без среды разработки, на мой взгляд, неоспорим
Мне кажется у автора некоторый комплекс развивается. Кажется многие программисты этим страдают. Внутри у всех бьется мысль — а если я ошибся, а если мой язык программирования не так хорош (а если С++ лучше, а если Java ...) Мне кажется тогда рождаются такие статьи которые пытаются прикрыть — перекричать какие-то изъяны технологии надуманные или нет. И вот что я скажу — нужно смотреть правде в глаза, лучше понять проблемы конкретной технологии и обратить это в плюс, а не прятаться. Даже я — не профессионал никогда не писавший на C# (Java && C++) вижу что аргументы слабы, а много где и спорны. Что толку кричать нет это миф! это миф! CLR так же быстра как и С++, ну господи, просто программируй кто не дает-та, чо ходить обращать в свою веру — не надо. Я вот с Java на С++ перешел — и не описуемо счастлив.
Вы бы спросили автора, а не разыгрывали тут доктора Хауса. Крута смотрится когда «не профессионал» «видит» ;). Разобрать ваш религиозный портрет? У меня это хобби.
Разберите пожалуйста, мне очень интересно (можно в личку), я люблю работать над собой и эта была моя основная мысль, а не то что я доктор «Хаус». И я не сомневаюсь что Вы поняли мою основную мысль.
И да я не профессионал в C#, но аналогии я проводить еще могу и логически мыслить тоже ;)
И да я не профессионал в C#, но аналогии я проводить еще могу и логически мыслить тоже ;)
>Вы бы спросили автора,
А чем спросить то? Мой пост вещь в себе, вопросов не имею :)
А чем спросить то? Мой пост вещь в себе, вопросов не имею :)
>> а если я ошибся, а если мой язык программирования не так хорош
Я считаю, что программировать ради языка программирования — неприбыльное занятие. В своё время сознательно выбрал C#/.Net именно из-за востребованности .Net приложений в enterprise секторе. До сих пор жалеть не приходилось.
А если вы пишете для развлечения — ну, тут языков много, есть, из чего выбрать.
Я считаю, что программировать ради языка программирования — неприбыльное занятие. В своё время сознательно выбрал C#/.Net именно из-за востребованности .Net приложений в enterprise секторе. До сих пор жалеть не приходилось.
А если вы пишете для развлечения — ну, тут языков много, есть, из чего выбрать.
Вы правы, однако для таких мастодонтов как С++, C#, Java вряд ли стоит ожидать упадка востребованности хоть в какой-то ближайшей перспективе ИМХО. Потому из этой тройки, как мне кажется, можно позволить себе то что больше нравится.
Хотя на все еще влияет окружающая среда, скажем у нас в городе востребованы по большей части Delphi программисты :)
Хотя на все еще влияет окружающая среда, скажем у нас в городе востребованы по большей части Delphi программисты :)
«Да, C# сейчас плотно обосновался в low-cost секторе enterprise — всё благодаря его характеристикам: на нем достаточно просто писать, статическая типизация и управляемая среда позволяет исключить целый класс ошибок, присущих скриптовым языками или языкам более низкого уровня, IDE предоставляет доступ ко всем нужным инструментам в пару кликов, встроенная прямо в IDE документация и первоклассный IntelliSense.
Благодаря этому решения на C#/CLR обходятся не так дорого, как в Java.»
А вот тут давайте разберем по косточкам, если никто не против?
Благодаря этому решения на C#/CLR обходятся не так дорого, как в Java.»
А вот тут давайте разберем по косточкам, если никто не против?
Да-да, я вот тоже не понимаю. Написано так, как будто для среды разработки на Java не обладают такими же великолепными фичами. IntelliSense у вижуал студии это детский лепет по сравнению с возможностями той же IntelliJ Idea (если не брать во внимание resharper от этой же конторы)
На джаве достаточно просто писать, татическая типизация и управляемая среда позволяет исключить целый класс ошибок, присущих скриптовым языками или языкам более низкого уровня
В общем, по-моему данный пункт здесь ни о чем.
На джаве достаточно просто писать, татическая типизация и управляемая среда позволяет исключить целый класс ошибок, присущих скриптовым языками или языкам более низкого уровня
В общем, по-моему данный пункт здесь ни о чем.
— Что есть low-cost enterpise?
— «На нем достаточно просто писать» — сложно писать на брейнфаке и фортране. На хаскелле и лиспе сложно и долго научиться, но потом можно писать (я думаю) тоже ничего так. На шарпе, яве, питоне, руби — писать в общем достаточно просто, таки да.
— Статическая типизация — она есть в Java / Scala. В С++ (если не злоупотреблять всякими reinterpret-cast-ми) она тоже есть.
— Управляемая среда — вы опять-таки не поверите, но и в Java она тоже есть! Управляемая среда была изобретена очень, ОЧЕНЬ давно. Я вспоминаю какую-то книжку Троелсена еще по второму дотнету, где тот расхваливал преимущества сборки мусора и управляемой среды, говорил что это — wave of future. Я конечно понимаю, это хороший маркетинговый ход, да, не все знают, что сборщик мусора как реально работающий концерт был уже ПЯТЬДЕСЯТ ЛЕТ НАЗАД в лиспе…
— «IDE предоставляет доступ ко всем нужным инструментам в пару кликов» — да, когда мы ставим поверх MSVS ReSharper от JetBrains-a, MSVS превращается в годную, юзабельную IDE. Т.е. практически, как IntelliJ IDEA!
— «встроенная прямо в IDE документация и первоклассный IntelliSense» — is not it something I've read about 1 million times on my screen while some IDE is being installed? :-D
Так опять, почему же решения обходятся не так дорого, как Java? И, кстати, заодно уж, а чего вы взяли, что решения на Java вообще дорого обходятся (и по чьим меркам).
Мое Саммари — написано хорошим языком, энергично, занимательно, с душком рекламы, самое то для привлечения начинающих на платформу дотнет.
— «На нем достаточно просто писать» — сложно писать на брейнфаке и фортране. На хаскелле и лиспе сложно и долго научиться, но потом можно писать (я думаю) тоже ничего так. На шарпе, яве, питоне, руби — писать в общем достаточно просто, таки да.
— Статическая типизация — она есть в Java / Scala. В С++ (если не злоупотреблять всякими reinterpret-cast-ми) она тоже есть.
— Управляемая среда — вы опять-таки не поверите, но и в Java она тоже есть! Управляемая среда была изобретена очень, ОЧЕНЬ давно. Я вспоминаю какую-то книжку Троелсена еще по второму дотнету, где тот расхваливал преимущества сборки мусора и управляемой среды, говорил что это — wave of future. Я конечно понимаю, это хороший маркетинговый ход, да, не все знают, что сборщик мусора как реально работающий концерт был уже ПЯТЬДЕСЯТ ЛЕТ НАЗАД в лиспе…
— «IDE предоставляет доступ ко всем нужным инструментам в пару кликов» — да, когда мы ставим поверх MSVS ReSharper от JetBrains-a, MSVS превращается в годную, юзабельную IDE. Т.е. практически, как IntelliJ IDEA!
— «встроенная прямо в IDE документация и первоклассный IntelliSense» — is not it something I've read about 1 million times on my screen while some IDE is being installed? :-D
Так опять, почему же решения обходятся не так дорого, как Java? И, кстати, заодно уж, а чего вы взяли, что решения на Java вообще дорого обходятся (и по чьим меркам).
Мое Саммари — написано хорошим языком, энергично, занимательно, с душком рекламы, самое то для привлечения начинающих на платформу дотнет.
В Java мало т.н. синтаксического сахара, который реально экономит время и делает код чище, понятнее и удобнее для оптимизации. Ни properties, ни events, ни лямда, ни расширенных методов, ни перегрузки методов, ни linq, просто назад в прошлое :)
Если рассматривать Java как платформу, а не как язык, то есть Scala / Groovy еще. и еще более 200 языков, портированных под JVM.
Интересно как у Scala / Groovy с IDE. Так же круто как для java?
Есть плагин к Idea для поддержки Scala, вполне себе крутой :)
Если не ошибаюсь, его в JetBrains пилят.
Еще есть scala-ide, но по ощущениям слабее плагина для Idea.
Если не ошибаюсь, его в JetBrains пилят.
Еще есть scala-ide, но по ощущениям слабее плагина для Idea.
Не могли бы вы сравнить, насколько он крут по сравнению с решарпером?
Слабее.
насколько слабее? Я тут быстро поискал, не нашел похожего на офиц сайт плагина — какую-то страничку на конфлюжнсе — там штук 6 рефакторингов и всё.
plugins.intellij.net/plugin/?id=1347
Автокомплит, сниппеты, менеджер проекта :) Всяких подсказок по коду не кажет.
Автокомплит, сниппеты, менеджер проекта :) Всяких подсказок по коду не кажет.
Нет — т.е. плагины есть, но они ограничены. Под динамические языки добиваться безукоризненного коде комплита в частности, очень трудно по понятным причинам.
Ой, сколько всяких языков винтом есть под .Net, но мы вроде бы про C# начинали?
Под перегрузкой методов что именно вы имели ввиду здесь?
Наверное то, что в джаве любой метод виртуальный по определению, а в шарпе — нет.
Разница только в умолчаниях. В Java тоже можно сделать невиртуальный метод.
«Под капотом» все методы в Jit-базированных платформах — виртуальные.
Это сделано для упрощения jitting-а. Все методы вызывают заглушку, в которой изначально вызов jitter-а этого метода, после того, как jitter отработал, вызов jitter-а патчится на вызов свещеиспеченного кода, расположение в памяти которого достаточно случайное.
Это сделано для упрощения jitting-а. Все методы вызывают заглушку, в которой изначально вызов jitter-а этого метода, после того, как jitter отработал, вызов jitter-а патчится на вызов свещеиспеченного кода, расположение в памяти которого достаточно случайное.
Интересно. А можно годную ссылку на подробности о работе джиттинга?
Ну уж не знаю, наверняка там тонкости есть. Например, может VM переджитит какой-то метод со статическим вызовом, если ей так будет угодно. Ну или это как-то может помочь инлайнингу в некоторых случаях. А вообще, посмотрел я VM Spec и не увидел какой-то специальной инструкции для невиртуального метода. Хотя с другой стороны, была же какая-то история, что у Vector все методы сделали final «для скорости», а потом все плевались.
Нет, видимо непонятно выразился.
В C# можно создавать методы с одинаковыми именами, но разными параметрами, а также методы с параметрами по умолчанию + вызывать такие методы с поименованными параметрами в удобном вам порядке…
Значитель упрощает перегрузку методов
В C# можно создавать методы с одинаковыми именами, но разными параметрами, а также методы с параметрами по умолчанию + вызывать такие методы с поименованными параметрами в удобном вам порядке…
Значитель упрощает перегрузку методов
Джава по сравнению с шарпом довольно унылый язык, лишенный кучи удобств последнего. Из собственного опыта (писал и на том и на другом) могу выделить следующие недостатки:
— нет свойств;
— нет лямбд и замыканий;
— нет событий;
— странный механизм аннотаций, который не такой эллегантный как атрибуты в шарпе;
— дженерики поддерживаются на уровне языка, но не на уровне виртуальной машины, что иногда приводит к неудобствам;
— linq — плюшка, без которой можно жить, но жизнь эта как-то уж очень уныла;
— нет вывода типов, динамиков, ко/контравариантности;
Навскидку не могу вспомнить ни одного плюса джавы, которого бы не хватало в шарпе. И это понятно — последний дизайнили исходя из недостатков и сильных сторон джавы.
Так вот весь этот набор плюшек как раз и определяет то, что для написания приложения на джаве нужно на пару десятков процентов больше времени, чем на шарпе, поэтому и выходит дороже. Впрочем, компенсируется эта дороговизна часто лицензиями на ОС, СУБД и т.п. Все дело в масштабах и конкретном проекте.
— нет свойств;
— нет лямбд и замыканий;
— нет событий;
— странный механизм аннотаций, который не такой эллегантный как атрибуты в шарпе;
— дженерики поддерживаются на уровне языка, но не на уровне виртуальной машины, что иногда приводит к неудобствам;
— linq — плюшка, без которой можно жить, но жизнь эта как-то уж очень уныла;
— нет вывода типов, динамиков, ко/контравариантности;
Навскидку не могу вспомнить ни одного плюса джавы, которого бы не хватало в шарпе. И это понятно — последний дизайнили исходя из недостатков и сильных сторон джавы.
Так вот весь этот набор плюшек как раз и определяет то, что для написания приложения на джаве нужно на пару десятков процентов больше времени, чем на шарпе, поэтому и выходит дороже. Впрочем, компенсируется эта дороговизна часто лицензиями на ОС, СУБД и т.п. Все дело в масштабах и конкретном проекте.
С другой стороны, C# и .NET в промышленную разработку ПО не принесли, по существу, ничего нового: сама концепция--из Java; ORM--порты с Java; MSBuild--по аналогии с Java Ant; generics--С++, Java; ко-контравариантность--не знаю откуда (shame on me), но точно не изобретение Microsoft; lambdas--из функциональных языков, еще в Javascript (1995 год) они есть; ASP.NET оказался не лучшим решением, хуже чем MVC-based; WPF--по аналогии с Qt (markup language, slots model); единственное, что приходит на ум--это LINQ, но ведь это стандартный функциональный подход + клевое название + маркетинговая кампания (хотя заслуга MS есть в том, что они добавили популярности функциональному подходу в императивных языках).
Ну это не недостаток языка, если он вобрал в себя все лучшее, что придумали до него. На самом деле очень рисковано пихать в мейнстрим язык фичи, которые перед этим не были обкатаны на каком-нибуть менее популярном языке.
Кстати, в 5 версии обещают офигенный новый синтаксис для работы с асинхронными вызовами — я такого не видел нигде пока.
Кстати, в 5 версии обещают офигенный новый синтаксис для работы с асинхронными вызовами — я такого не видел нигде пока.
Причем здесь Qt? HTML, XML и Delphi DFM форматы были задолго до Qt…
На Asp.Net пишется немеренное количество веб-приложений, новый Asp.Net MVC сделан для тех, кто привык делать всё по раздельности.
Порты явовских библиотек после их реального использования не кажутся уже удобными, после linq2sql, nHibernate сосёт со своей linq-реализацией. А сколько там багов — уже даже лень перечислять. Log4net во многом уступает nLog-у, более ничего полезного в Яве лично мной не замечено.
Ant — это make, который есть в любом c компиляторе, тоже ничего нового.
Странно, но все библиотеки где-то когда-то появились первыми. И не факт, что в Яве.
На Asp.Net пишется немеренное количество веб-приложений, новый Asp.Net MVC сделан для тех, кто привык делать всё по раздельности.
Порты явовских библиотек после их реального использования не кажутся уже удобными, после linq2sql, nHibernate сосёт со своей linq-реализацией. А сколько там багов — уже даже лень перечислять. Log4net во многом уступает nLog-у, более ничего полезного в Яве лично мной не замечено.
Ant — это make, который есть в любом c компиляторе, тоже ничего нового.
Странно, но все библиотеки где-то когда-то появились первыми. И не факт, что в Яве.
Вы дейстивтельно думаете, что Ант и мейк — одно и тоже? И что это включено в компилятор?:)
Сколько себя помню, make шел с Visual C++, nmake с Delphi и Borland C++…
Не хочу сказать, что ant и make это одно и тоже, хочу сказать, что до Ant-а было make, которые делал то же самое, немного по-другому, но судь build tool от этого не меняется, как вы его не назовите. Ini-файл, Text-файл или Xml-файл на входе — это детали, возможности расширения в make тоже были…
Не хочу сказать, что ant и make это одно и тоже, хочу сказать, что до Ant-а было make, которые делал то же самое, немного по-другому, но судь build tool от этого не меняется, как вы его не назовите. Ini-файл, Text-файл или Xml-файл на входе — это детали, возможности расширения в make тоже были…
Я пытаюсь показать, что .Net как платформа всегда вторичен (как ни горько это признаваь--я сам .Net разработчик). Своих удачных новаторских решений у MS .NET почти нет. Либо они перенимают что-то хорошее из других языков, либо делают что-то свое--но не очень хорошо (в смысле концепции и архитектуры; багов действительно мало). Никто, насколько я знаю, всерьез не переносит ASP.NET, WPF, MSBuild на другие платформы разработки. Единственное исключение--это Linq to objects.
Вторичен, не вторичен, суть не в этом…
Просто индустрия плодит алмазы то там, то здесь. Собирать их по разным платформам, языкам, технологиям — неблагодарное, трудоемкое дело. Скокать с одного языка на другой, с одной либы на другую, с рельсов на джангу, с джанги на чунга-чангу, типо там фишка новая — тоже уже не вьюношы давно.
А в C#/.NET Microsoft регулярно собирает все самое лучшее из других языков/платформ в новый релиз.
По-моему, просто чудесно. И волки сыты, и овцы целы.
Просто индустрия плодит алмазы то там, то здесь. Собирать их по разным платформам, языкам, технологиям — неблагодарное, трудоемкое дело. Скокать с одного языка на другой, с одной либы на другую, с рельсов на джангу, с джанги на чунга-чангу, типо там фишка новая — тоже уже не вьюношы давно.
А в C#/.NET Microsoft регулярно собирает все самое лучшее из других языков/платформ в новый релиз.
По-моему, просто чудесно. И волки сыты, и овцы целы.
— нет свойств;
— нет событий;
Ну это не так страшно. getter/setter сгенерить может IDE. А события замещаются ручной реализацией соответствующего паттерно. Обидно, конечно, но не фатально
— нет лямбд и замыканий;
Есть анонимные классы, и таки немного замыкания. Причём замыкания там даже более каноничные, ведь они же изначально пришли из функциональных языков, где переменные иммутабельны. Почему раз сумели сделать анонимные классы, не сделали анонимных функций — загадка.
— странный механизм аннотаций, который не такой эллегантный как атрибуты в шарпе;
Чем же он не такой элегантный?
— дженерики поддерживаются на уровне языка, но не на уровне виртуальной машины, что иногда приводит к неудобствам;
Да, вот это страшно. Особенно удручает то, что «благодаря» такому механизму мне ничего не остаётся делать, кроме как городить @SuppressWarnings, чтобы при моих настройках IDE не показывал warning'ов (они непротиворечивые, но строгие). Но, как я понял, это было сделано специально, ибо к тому времени, как для Java сделали generics, она была старше и пришлось бы дублировать больший функционал, чем в C# (а в C# его продублировали — см, например, System.Collections и System.Collections.Generic).
— нет вывода типов, динамиков, ко/контравариантности;
Динамики не нужны :-) Вывод типов для переменных действительно отсутствует. Зато он есть для generic'ов, и на топ спасибо. Ко/контрвариантность таки есть.
Зато добавлю от себя более значительных минусов:
— checked exceptions. В принципе, штука имеющая право на существование. Но я всё же за выбрасывание unchecked exceptions. Всё бы ничего, да вот очень многие вещи в JDK выбрасывают checked exceptions. Особенно страшная в этом смысле ситуация с reflection.
— отсутствие аналога IDisposable/using. Для эмуляции схожего функционала приходится городить нечто страшное. Или нагородить кучу helper-методов для безопасного освобождения ресурсов и использовать чуть менее страшную конструкцию.
— отсутствие генераторов (yield return). В связи с этим реализация Iterable — работа для настоящих джедаев. Посему в Java, там где уместно использовать генератор, принято постоянно создавать и заполнять кучу небольших ArrayList'ов, что негативно сказывается на производительности. Впрочем, есть маленький плюс — генераторы сложнее отлаживать.
Обидно, конечно, но не фатально
Если бы в джаве были фатальные неудобства, то она не была бы столь популярна. Благодаря событиям, свойствам и лямбдам код на шарпе выглядит куда более читаемым, компактным и простым. Это собственно и все их преимущество.
Почему раз сумели сделать анонимные классы, не сделали анонимных функций — загадка.Кстати о лямбдах, я имею ввиду не только грубо говоря Func<int, int, int>, но и Expression<Func<int, int, int>> — в умелых руках этот механизм превращается просто в убийственную штуку.
Чем же он не такой элегантный?
Возможно я не до конца разобрался, но насколько я понял, аннотация в джаве — это всегда интерфейс, который не может содержать никакой логики, только данные. Атрибуты в шарпе — это полноценные классы, в которых можно (пере)определить некую логику. Самый простой пример, где это используется — Action Filters в ASP.Net MVC.
Динамики не нужны :-)Вам, видимо, не нужны :) Я тоже редко пользуюсь, но иногда это просто замечательная вещь.
А про yield, using и checked exceptions сам хотел написать, но забыл :)
Анонимных функций сделать в яве не смогли потому, что в яве функций нет вообще. Потому, наиболее удобный костыль, который смогли придумать — использовать анонимный / локальный класс с некоторым количеством методов.
Об этом хорошо писал еще автор Groovy in Action.
Примерно так:
В Java нет такого понятия, как функция, висящая в воздухе, а есть только классы и их методы (ну и 8 примитивных типов, которые нарушают принцип Все Есть Объект во имя производительности).
В свою очередь, код может быть определен только или внутри методов, или внутри инициализаторов классов. Т.е., нельзя просто «создать некоторый кусок кода и передать его куда то», или «применить определенный код в каком-то контексте, например, к каждому элементу коллекции». И прочее.
В Groovy для поддержки замыкания на уровня языка (и поддержки получающегося байткод совместимым с JVM), было нагорожено довольно немало.
Я думаю, это интересная тема для отдельного поста, кстати. Как реализуются замыкания поверх JVM.
Об этом хорошо писал еще автор Groovy in Action.
Примерно так:
В Java нет такого понятия, как функция, висящая в воздухе, а есть только классы и их методы (ну и 8 примитивных типов, которые нарушают принцип Все Есть Объект во имя производительности).
В свою очередь, код может быть определен только или внутри методов, или внутри инициализаторов классов. Т.е., нельзя просто «создать некоторый кусок кода и передать его куда то», или «применить определенный код в каком-то контексте, например, к каждому элементу коллекции». И прочее.
В Groovy для поддержки замыкания на уровня языка (и поддержки получающегося байткод совместимым с JVM), было нагорожено довольно немало.
Я думаю, это интересная тема для отдельного поста, кстати. Как реализуются замыкания поверх JVM.
Я вам скажу по секрету, что в CLR тоже нет функций без классов. Когда вы пишете лямбду — компилятор создает анонимный класс и помещает лямбду в него как метод. Переменные, попавшие в замыкание становятся полями этого класса. Просто этой работой занимается не программист, а компилятор.
> Я думаю, это интересная тема для отдельного поста, кстати. Как реализуются замыкания поверх JVM.
А что тут интересного? Если всё так, как я думаю, тогда просто на каждую переменную, на которую мы ссылаемся из анонимного класса, создаётся поле у этого класса и при создании экземпляра класса значение переменной просто копируется в это поле. Потому, видимо, и ввели требование на то, чтобы переменные, видимые в анонимном классе, были final.
А что тут интересного? Если всё так, как я думаю, тогда просто на каждую переменную, на которую мы ссылаемся из анонимного класса, создаётся поле у этого класса и при создании экземпляра класса значение переменной просто копируется в это поле. Потому, видимо, и ввели требование на то, чтобы переменные, видимые в анонимном классе, были final.
Черт побери!
Автор топика должен быть написать то, что написали вы, и я бы и не нашел что возразить.
Вот это — да, грамотный ответ.
Что только хочу добавить:
— по моему убеждению, Java должна стать платформой для хостинга языков, таких, как Scala, Groovy, Jython etc. А Java пусть будет самым отточенным (при этом во многом законсервированным) и оптимизированным «дефолтным» языком под JVM.
Вот тогда, эта платформа еще очень долго будет привлекательной не только для тяжелого Enterprise-a.
Автор топика должен быть написать то, что написали вы, и я бы и не нашел что возразить.
Вот это — да, грамотный ответ.
Что только хочу добавить:
— по моему убеждению, Java должна стать платформой для хостинга языков, таких, как Scala, Groovy, Jython etc. А Java пусть будет самым отточенным (при этом во многом законсервированным) и оптимизированным «дефолтным» языком под JVM.
Вот тогда, эта платформа еще очень долго будет привлекательной не только для тяжелого Enterprise-a.
На деле не так. Сколько процентов людей используют указанные альтернативные языки в продакшен коде? А не для упрощения билда, автоматизации текущих задач? Очень мало кто. Конечно, эти альтернативные языки часто сыроваты, так что осторожность оправданна. Но — курсом развития для JVM должно стать — развитие альтернативных языков под JVM!
Ещё напишите какие платформы поддерживает .net. На C# можно писать под windows, win mobile (.net cf), win phone 7 (sl, xna), zune и xbox (xna). Можно писать под embeded платформы на .net mf, а благодаря mono ещё можно писать под macos, iPhone, iPad и Android.
статья прикольная. Если нирвана (а вместе с ней и абсолютное спокойствие) еще не достигнуто, то так и хочется чего-нить ответить, либо в защиту CLR либо языка ZZZ.
Не думаю, что ситуация с С#/CLR чем -то отличется от любой новой технологии или идей.
В средние века арбалет вытеснял лук как оружие дальнего боя (не надо долго учить стрелка), потом аркебуза/ ружье пришло на смену(стреляет дальше, и пробивает броню). Еще раньше, проверенных механизм (каток) был заменен новомодной диковинкой (колесо назвывается), самолеты пришли на смену дирижаблям (хотя они и сейчас используются, лично видел).
Всегда изобретаются новые технологии, которые позволяют делать что-то лучше, или проще. Большинство технологий начинают с детскими болезнями, потом взрослеют, развиваются, и наконец, переходят в разряд старых технологий, которые заменяются другими
У любой технологии вначале всегда больше критиков, потом она потихоньку проникает в сознание, изучается, и принимается большинством.
Так что что мы можем выплеснуть эмоции, защишая/ критикую что-то, или переломить себя (мне, например, сложно признать, что я еще не все знаю) и начать изучать что-то новое.
Не думаю, что ситуация с С#/CLR чем -то отличется от любой новой технологии или идей.
В средние века арбалет вытеснял лук как оружие дальнего боя (не надо долго учить стрелка), потом аркебуза/ ружье пришло на смену(стреляет дальше, и пробивает броню). Еще раньше, проверенных механизм (каток) был заменен новомодной диковинкой (колесо назвывается), самолеты пришли на смену дирижаблям (хотя они и сейчас используются, лично видел).
Всегда изобретаются новые технологии, которые позволяют делать что-то лучше, или проще. Большинство технологий начинают с детскими болезнями, потом взрослеют, развиваются, и наконец, переходят в разряд старых технологий, которые заменяются другими
У любой технологии вначале всегда больше критиков, потом она потихоньку проникает в сознание, изучается, и принимается большинством.
Так что что мы можем выплеснуть эмоции, защишая/ критикую что-то, или переломить себя (мне, например, сложно признать, что я еще не все знаю) и начать изучать что-то новое.
Сам последние 8 лет работаю с .NET C#, но как то не понял, для кого эта статья. Любой человек, кто более менее серьезно работает с .NET большинство перечисленных вещей знает и так, а «мифы» и их опровержения перечисленные выше, это похоже на слухи, которые кто-то когда то услышал в трамвае, и вот сейчас мы всех выведем на чистую воду. Если человек верил в эти мифы, значит он или никогда не интересовался .NET или этот самый .NET ему на фиг не нужен, потому что он любит Java, php, Ruby и т.д. и опровергнув эти слухи уж точно нельзя никого переманить из одного лагеря в другой.
Было бы интересно почитать какое-нибудь исследование где бы сравнивались разные языки и платформы на предмет производительности, скорости разработки, требований к ресурсам. А так это действительно просто очередная статья для холивара, чтобы помериться у кого что лучше.
Было бы интересно почитать какое-нибудь исследование где бы сравнивались разные языки и платформы на предмет производительности, скорости разработки, требований к ресурсам. А так это действительно просто очередная статья для холивара, чтобы помериться у кого что лучше.
>Если человек верил в эти мифы, значит он или никогда не интересовался .NET или этот самый .NET ему на фиг не нужен, потому что он любит Java, php, Ruby и т.д. и опровергнув эти слухи уж точно нельзя никого переманить из одного лагеря в другой.
Верил-не верил, но слышал и заметочку сделал — «не бывает дыма без огня». Ах, да, .NET я никогда не интересовался, а вот Mono интересуюсь и стараюсь учитывать все мнения, чтобы понять готов ли он (или готово ли оно? :) ) для продакшена в вебе под Linux и какие плюсы/минусы по сравнению с PHP/Python я получу, если что, скажу своей нынешней «жене» и «любовнице»: «Ничего личного, just a business» :). Язык С# мне нравится, а вот среда выполнения от MS нет. Но как-то так получилось, что многое про .NET относится и к Mono, плюс свои мифы (или факты — не знаю). Многие (причём с обеих сторон, и со стороны .NET, и со стороны Linux) считают, что Mono не готов к продакшену и даже вряд ли будет готов когда-нибудь, а тут противоположное мнение (редкое, имхо). Эта статья добавила ещё одну каплю в «чашу терпения»: может всё-таки перейти к чему-то большему c C#, чем написание «Hello world» в «блокноте» (gedit) и радостному убеждению, что hello.exe работает и в Linux, и в Windows.
Верил-не верил, но слышал и заметочку сделал — «не бывает дыма без огня». Ах, да, .NET я никогда не интересовался, а вот Mono интересуюсь и стараюсь учитывать все мнения, чтобы понять готов ли он (или готово ли оно? :) ) для продакшена в вебе под Linux и какие плюсы/минусы по сравнению с PHP/Python я получу, если что, скажу своей нынешней «жене» и «любовнице»: «Ничего личного, just a business» :). Язык С# мне нравится, а вот среда выполнения от MS нет. Но как-то так получилось, что многое про .NET относится и к Mono, плюс свои мифы (или факты — не знаю). Многие (причём с обеих сторон, и со стороны .NET, и со стороны Linux) считают, что Mono не готов к продакшену и даже вряд ли будет готов когда-нибудь, а тут противоположное мнение (редкое, имхо). Эта статья добавила ещё одну каплю в «чашу терпения»: может всё-таки перейти к чему-то большему c C#, чем написание «Hello world» в «блокноте» (gedit) и радостному убеждению, что hello.exe работает и в Linux, и в Windows.
До тех пор, пока .Net и т.д. не будет Open Source, я даже глазом не посмотрю в ее сторону.
Я поковырял когда-то asp.net, и плюнулся. Зависимости от чужих компонентов, и от самого Microsoft — это перечеркивает все плюсы.
То ли дело Ява или плюсы. Никто к тебе не доебется на тему лицензий. И самому можно допиливать, как угодно.
Я поковырял когда-то asp.net, и плюнулся. Зависимости от чужих компонентов, и от самого Microsoft — это перечеркивает все плюсы.
То ли дело Ява или плюсы. Никто к тебе не доебется на тему лицензий. И самому можно допиливать, как угодно.
Я думал это итак всем известно. Хоть я и не пишу на C# да и не знаю его толком, но такие базовые вещи итак понятны.
мои две капли в пузомерку :))):
в Германии технологии MS .NET, C#, SQL-Server устойчиво занимают «солидные» 3% (!!!) рынка
что примерно соответствует названию производящей их компании:
www.gulp.de/kb/tools/gulpometer.html
под «рынком», в данном конкретном случае, я подразумеваю рынок проектов для фриленца. все остальное мне, по большому счету, глубоко «фиолетово»
в больших корпоративных кросплатформ. проектах java, на сегодня, — это стандарт «де-факто»
в Германии технологии MS .NET, C#, SQL-Server устойчиво занимают «солидные» 3% (!!!) рынка
что примерно соответствует названию производящей их компании:
www.gulp.de/kb/tools/gulpometer.html
под «рынком», в данном конкретном случае, я подразумеваю рынок проектов для фриленца. все остальное мне, по большому счету, глубоко «фиолетово»
в больших корпоративных кросплатформ. проектах java, на сегодня, — это стандарт «де-факто»
Странно. А вот у нас в Германии 3% рынка занимает Java…
Вы наверное из восточной, где до сих пор верят в халяву?
Вы наверное из восточной, где до сих пор верят в халяву?
прочитайте мой пост внимательней
Java была стандартом «де-факто» в 2005 года. Теперь это уже не показатель…
Фрилансеров берут для поддержки морально устаревшего барахла, новый серьезный софт разрабатывают конторы, специализирующиеся на этом. А те умеют экономить свое время, поэтому давно перешли на .Net…
В финансовом секторе, где я работаю последние 10 лет во франкфурте, еще осталось куча говна, написанного на Яве, которую клиенты просто не хотят переписывать изза отсутствия пока что денег. Но когда то деньги появятся, уверен на 100 процентов
Фрилансеров берут для поддержки морально устаревшего барахла, новый серьезный софт разрабатывают конторы, специализирующиеся на этом. А те умеют экономить свое время, поэтому давно перешли на .Net…
В финансовом секторе, где я работаю последние 10 лет во франкфурте, еще осталось куча говна, написанного на Яве, которую клиенты просто не хотят переписывать изза отсутствия пока что денег. Но когда то деньги появятся, уверен на 100 процентов
Это тоже не показатель. Всегда надо выбирать инструмент под задачу.
Пример: Лондонская биржа, которая (внимание!) совместно с микрософтом не смогли решить задачу под .NET и перешли на ORACLE/Java.
Вот вам Финансовый сектор и «морально устаревшее барахло».
Пример: Лондонская биржа, которая (внимание!) совместно с микрософтом не смогли решить задачу под .NET и перешли на ORACLE/Java.
Вот вам Финансовый сектор и «морально устаревшее барахло».
Это известный пример, когда головную боль вылечили гильотиной.
Написали говеный софт, пытались его в процесе пофиксить, где-то опять лоханулись, CEO сняли, поставили другого, он купил альтернативный софт. Софт, как оказалось по MSSQL не работает, пришлось им и базу менять. А софту по-парабану, на каком сервере Oracle работает. Вот и решили сэкономить.
Уверен, что найдутся люди, которые будут утверждать, что Oracle работает под линухом стабильнее — не знаю. Знаю, что в Германии в одной мэрии в Баварии из-за бага в линуксовской версии Оракла, потеряли всю базу. Бэкап (свято верили в Оракловских индусов) делали за месяц до этого…
Вот вам и хваленый Оракл под линух. Хорошо, что под Windows новые версии выходят не сразу. А после того, как их на других осях обкатают.
Написали говеный софт, пытались его в процесе пофиксить, где-то опять лоханулись, CEO сняли, поставили другого, он купил альтернативный софт. Софт, как оказалось по MSSQL не работает, пришлось им и базу менять. А софту по-парабану, на каком сервере Oracle работает. Вот и решили сэкономить.
Уверен, что найдутся люди, которые будут утверждать, что Oracle работает под линухом стабильнее — не знаю. Знаю, что в Германии в одной мэрии в Баварии из-за бага в линуксовской версии Оракла, потеряли всю базу. Бэкап (свято верили в Оракловских индусов) делали за месяц до этого…
Вот вам и хваленый Оракл под линух. Хорошо, что под Windows новые версии выходят не сразу. А после того, как их на других осях обкатают.
не надо рассказывать сказки. я вам привел статистику www.gulp.de
это статистика — она обьективна
.NET принципиально не вписывается в 3-Tier Architecture компаний в которых я работал и работаю — это Deutsche Bahn (Db-Systel) и Deutsche Telekom(T-Systems)
это статистика — она обьективна
.NET принципиально не вписывается в 3-Tier Architecture компаний в которых я работал и работаю — это Deutsche Bahn (Db-Systel) и Deutsche Telekom(T-Systems)
Не знаю как там в Телекоме, далеко от финансов. Но в DB Silverlight входит в стандартную комплектацию клиентских машин, в DWS тоже. В Helabe пытались заставить народ под линух писать, но быстрее вышло на Asp.Net и под винду.
Мой новый проект — целиком 3 Tier out-of-browser web-приложение на Silverlight, будет работать во всех банках.
Я не знаю, под что у людей руки заточены, если они 3-Tier архитектуру на .Net находят сложной. После Java и проблем с разными апп-серверами, WCF как глоток свежего воздуха…
Мой новый проект — целиком 3 Tier out-of-browser web-приложение на Silverlight, будет работать во всех банках.
Я не знаю, под что у людей руки заточены, если они 3-Tier архитектуру на .Net находят сложной. После Java и проблем с разными апп-серверами, WCF как глоток свежего воздуха…
Я сисадмин и ничего не смыслю в программировании, но с программами на .NET встречаюсь почти каждый день с тем, что эти программы очень долго грузятся и тормозят — раз, и что им нужен framework.
Второе особенно ужасно, потому что абсолютно типичная ситуация когда программе нужен framework 1.1 и то что установлен 2.0 ей по барабану. А той, что требует 3.5 совершенно плевать на то что установлен 4.0. И так далее.
Установка же этих фреймворков тоже цирк — тот же 3.5 в виде «полного» пакета на 231 Мб зачем то при установке лезет в сеть чтобы докачать ещё мегабайт 80.
А ставится по времени столько же сколько Windows 2008 Server.
В общем если есть две одинаковых проги — одна под .NET другая на C++ — я выберу вторую.
Второе особенно ужасно, потому что абсолютно типичная ситуация когда программе нужен framework 1.1 и то что установлен 2.0 ей по барабану. А той, что требует 3.5 совершенно плевать на то что установлен 4.0. И так далее.
Установка же этих фреймворков тоже цирк — тот же 3.5 в виде «полного» пакета на 231 Мб зачем то при установке лезет в сеть чтобы докачать ещё мегабайт 80.
А ставится по времени столько же сколько Windows 2008 Server.
В общем если есть две одинаковых проги — одна под .NET другая на C++ — я выберу вторую.
1.1 — это, к примеру, как mfc70, 2.0-3.5 — это как mfc71, 4.0 — mfc80.
Теперь понятно, почему они друг дружку не видят? Названия файлов разные :)
Кроме того, как сисадмин, вы должны знать про файлы манифестов, как одним xml-файлом можно заставить приложение для 1.1 фреймворка использовать 2.0…
Да, и наш админ включает .NET framework в master образ операционки, который он разворачивает потом на новых компах. т.е. .NET есть на компе изначально. Экономит массу времени, и админа, и пользователя.
Но вы как сисадмин всё это, конечно, знаете…
Теперь понятно, почему они друг дружку не видят? Названия файлов разные :)
Кроме того, как сисадмин, вы должны знать про файлы манифестов, как одним xml-файлом можно заставить приложение для 1.1 фреймворка использовать 2.0…
Да, и наш админ включает .NET framework в master образ операционки, который он разворачивает потом на новых компах. т.е. .NET есть на компе изначально. Экономит массу времени, и админа, и пользователя.
Но вы как сисадмин всё это, конечно, знаете…
Как сисадмин я не хочу заниматься тем чтобы заставлять приложение что-то использовать — оно либо работает без лишнего скрипа, либо я ищу альтернативу, благо почти всегда таковая есть.
Потому что необходимость обработки напильником после установки говорит не в пользу разработчиков.
А какой из фреймворков включать в образ если разные программы хотят разные их версии? Я уже давным давно включаю в образ 2.0 — но это совершенно не защищает от просьб всяких программ поставить то 1.1 то 3.0 то ещё какой-то.
В результате почти на всех машинах стоят (спасибо WSUS-у) сразу все фреймворки:
1.1 2.0 3.0 3.5 4.0
Стоит отдать должное что они друг другу не мешают и именно а такой конфигурации все программы под .NET нормально работают.
Но это уже какой-то dependency hell начинается, хотя речь и не о линуксе.
Потому что необходимость обработки напильником после установки говорит не в пользу разработчиков.
А какой из фреймворков включать в образ если разные программы хотят разные их версии? Я уже давным давно включаю в образ 2.0 — но это совершенно не защищает от просьб всяких программ поставить то 1.1 то 3.0 то ещё какой-то.
В результате почти на всех машинах стоят (спасибо WSUS-у) сразу все фреймворки:
1.1 2.0 3.0 3.5 4.0
Стоит отдать должное что они друг другу не мешают и именно а такой конфигурации все программы под .NET нормально работают.
Но это уже какой-то dependency hell начинается, хотя речь и не о линуксе.
Хабр взорван, мда.
Язык нужно выбирать под задачу, да. И. Если бы я мастерски владел обоими языками, то для высоко нагруженных выбирал бы C++, а для запускаемых редко — C#, с учётом баланса по времени разработки.
По мне так чем выше нагрузка на приложение, тем более низкий уровень языка надо выбирать, дабы иметь контроль над тонкостями. Чем выше нагрузка — тем больше тонкостей может всплыть на шарпе и тем меньше граблей мы получим на плюсах, это при одном и том же уровне владения языками, постольку поскольку плюсы — это по определению бОльший контроль над программой. А при высокой нагрузке если не проконтролировал лишний раз ситуацию — получаешь «плюху», обязательно сработает закон Мерфи.
Посему холивары они и в Африке — holy.
Язык нужно выбирать под задачу, да. И. Если бы я мастерски владел обоими языками, то для высоко нагруженных выбирал бы C++, а для запускаемых редко — C#, с учётом баланса по времени разработки.
По мне так чем выше нагрузка на приложение, тем более низкий уровень языка надо выбирать, дабы иметь контроль над тонкостями. Чем выше нагрузка — тем больше тонкостей может всплыть на шарпе и тем меньше граблей мы получим на плюсах, это при одном и том же уровне владения языками, постольку поскольку плюсы — это по определению бОльший контроль над программой. А при высокой нагрузке если не проконтролировал лишний раз ситуацию — получаешь «плюху», обязательно сработает закон Мерфи.
Посему холивары они и в Африке — holy.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мифы и заблуждения насчёт CLR и .NET