Какой шикарный флейм однако....
Так вот, продолжая популярную мыльную оперу...
.Net, нет, и по-видимому, не будет места при разработке приложений:

1)Критичных к скорости выполнения
2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных
3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )
4) Производящих обсчет данных с плавающей точкой, итерационными алгоритмами и n- методами

А для всего остального .Нет подходит так же, как и другое средство программирования...


Есть возражения ?

NN>1)Критичных к скорости выполнения

Примеры давай приведем, а?
Ну, RTS в расчет вообще не берем — там без вопросов, а что-то из жизни?
Архиватор? кодек? Шифрование и обработка растровой графики?
Настолько ли там это все критично?

Или все-таки самые-самые важные участки все одно пишутся на асме с жесткой оптимизацией, а все остальное — вполне можно на .net?


NN>2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных

Ммм? Объясни, почему. Мне неочевидно.

NN>3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )

Чего-чего???? Я что-то не пойму, кк трафик, передаваемый например, по протоколу FTP может зависеть от средств реализации оконечных программ клиента и сервера.

NN>4) Производящих обсчет данных с плавающей точкой, итерационными алгоритмами и n- методами

Тоже не понимаю. Разве в native C++ выражение 1.123/3.321 даст результат отличный от результата этого же выражения в managed C++?

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

NN>>3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )

iT>Чего-чего???? Я что-то не пойму, кк трафик, передаваемый например, по протоколу FTP может зависеть от средств реализации оконечных программ клиента и сервера.

видимо человек услышал про то, что .НЕТ хорошо дружит с SOAP'ом, а что SOAP по объему своих текстовых данных превышает во много раз бинарный поток — это и ежу ясно (и на этот SOAP огрызаются те, кто не подумав решил его использовать там, где ему не место... Была тут ветка на РСДН про XML с гневными эмоциями на него.). Он прежде всего сделан для передачи данных через фаерволы (та же Ява с SOAPом использует аж бегом). Если критичен траффик — свой алгоритм сжатия или еще какой-нибудь и вперед. .НЕТ конечно тут не при чем.

Вот так и рождаются байки про то, что что-то где-то плохо работает.

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

iT>Архиватор? кодек? Шифрование и обработка растровой графики?

Думаешь выход, например, кодека DivX на .net возможен? (это я не для флейма спрашиваю ;)

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

NN>>1)Критичных к скорости выполнения
iT>Примеры давай приведем, а?
iT>Ну, RTS в расчет вообще не берем — там без вопросов, а что-то из жизни?
iT>Архиватор? кодек? Шифрование и обработка растровой графики?
iT>Настолько ли там это все критично?
А чему же ещё там быть критичным? Если тот же 7zip переписать под дотНЕТ, то архивировать он станет здорово дольше. Т.е. вместо 2-х часов будет работать, скажем, три. Это уже очень неприятно. Но это пример из повседневности. А вот если обсчёт какой-то задачи будет идти вместо 2-х месяцев — три, то это уже большие деньги. В таких задачах дотНЕТ действительно делать нечего.

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

R>А чему же ещё там быть критичным? Если тот же 7zip переписать под дотНЕТ, то архивировать он станет здорово дольше.

Не забываем про MC++? Например, zlib переносится на MC++ на раз-два и работает так же быстро. При желании такие участки кода можно сразу компилировать в native-код, разницы не будет совсем никакой.

R>В таких задачах дотНЕТ действительно делать нечего.

Ты забываешь, что в отличии от Java, .NET != C# и в нём есть место любым языкам. В частности C++, на котором написано всё о чём ты говоришь. Соответственно остаются все доступные методы отпимизации и пр.

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

NN>.Net, нет, и по-видимому, не будет места при разработке приложений:
NN>1)Критичных к скорости выполнения
NN>2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных
NN>3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )
NN>4) Производящих обсчет данных с плавающей точкой, итерационными алгоритмами и n- методами

На данный момент места .NET нет в разработке приложений для обычных пользователей: слишком немногие имеют его на своих машинах. Впрочем, лет через пять, возможно, будет иметь смысл думать об этом .

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

R>Здравствуйте, Igor Trofimov, Вы писали:

R>А чему же ещё там быть критичным? Если тот же 7zip переписать под дотНЕТ, то архивировать он станет здорово дольше. Т.е. вместо 2-х часов будет работать, скажем, три. Это уже очень неприятно. Но это пример из повседневности. А вот если обсчёт какой-то задачи будет идти вместо 2-х месяцев — три, то это уже большие деньги. В таких задачах дотНЕТ действительно делать нечего.

а если переписать на ассемблер обсчет задачи, которая написана на С++ и выполняется 2 месяца, то она будет выполняться полмесяца. Сколько денег экономим. А теперь если посчитать, сколько времени и денег обойдется написание нам этой задачи, то нет уж, лучше пусть считает 2 месяца

ЗЫ. Под .НЕТ есть С++.NET, тот же unfase кол

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

NN>>1)Критичных к скорости выполнения

iT>Примеры давай приведем, а?
iT>Ну, RTS в расчет вообще не берем — там без вопросов, а что-то из жизни?

А почему не берем? RTS — это как я понял Real Time Strategy? Если так, то по критичности скорости выполнения это примерно то же самое, что и First Person Shooter.

Ок, смотрим сюда.

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

HN>А почему не берем? RTS — это как я понял Real Time Strategy?

Real-Time System,
Система которая гарантированно обрабатывает все поступившие запросы.
Системы жизнеобеспечения, опасные процессы, всё что при неправильном функционировании несёт опасность для жизни и вред здоровью управляется только такими системами. Прикинь, если на АЭС комп проглотит сообщение о повышении температуры в реакторе? Нехорошо будет, однако
Всё Java-based/.Net-based это не RTS по определению. Об этом заявляют и Sun и MS весьма прямо.

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

IT>Не забываем про MC++? Например, zlib переносится на MC++ на раз-два и работает так же быстро. При желании такие участки кода можно сразу компилировать в native-код, разницы не будет совсем никакой.

Спрашивается, зачем переносить на .Net код который не будет использовать возможностей .Net?
Тогда давайте писать для С++ компилятора, но без класов и перегруженных функций. Зато для С++ компилятора — это круто. Давайте не запускать на windows более одного процесса, чтоб ему всё время досталось и.т.д.
Все вычислительные задачи однозначно не для .Net. Это проверенный факт.

IT>Ты забываешь, что в отличии от Java, .NET != C# и в нём есть место любым языкам. В частности C++, на котором написано всё о чём ты говоришь. Соответственно остаются все доступные методы отпимизации и пр.
Или да или нет

Автор(ы): Максим Шеманарев
Дата: 29.03.2003

Hello, "adontz"
> HN>А почему не берем? RTS — это как я понял Real Time Strategy?
>
> Real-Time System,
> Система которая гарантированно обрабатывает все поступившие запросы.

Наверное все-таки не гарантированно, а за гарантированное время.

> Системы жизнеобеспечения, опасные процессы, всё что при неправильном функционировании несёт опасность для жизни и вред здоровью управляется только такими системами. Прикинь, если на АЭС комп проглотит сообщение о повышении температуры в реакторе? Нехорошо будет, однако
>

Сообщение никто не проглотит. Другое дело, что таже java не может гарантировать, что сообщение о превышении температуры будет доставлено оператору например за 1сек максимум.

Hello, "adontz"
>
> Все вычислительные задачи однозначно не для .Net. Это проверенный факт.

А для чего? Возможное падение производительности процессора на 10% это существенный факт?
Да и потом — .NET широкая это платформа, а не один конкретный язык со всеми его недостатками.
А факт/не факт — с тем-же успехом, можно сказать, что вычислительные задачи однозначно не для AMD

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

A>Спрашивается, зачем переносить на .Net код который не будет использовать возможностей .Net?

Как зачем, чтобы .NET использовал его возможности.

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

A>На данный момент места .NET нет в разработке приложений для обычных пользователей: слишком немногие имеют его на своих машинах. Впрочем, лет через пять, возможно, будет иметь смысл думать об этом .

Думаю раньше. В 95 совсем не многие имели W95 на своих машинах и разработке Win32 приложений по твоему определению не было места. В 97 такие таребования были обычным делом. И даже наоборот, места не стало для разработки DOS приложений.

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

>> Системы жизнеобеспечения, опасные процессы, всё что при неправильном функционировании несёт опасность для жизни и вред здоровью управляется только такими системами. Прикинь, если на АЭС комп проглотит сообщение о повышении температуры в реакторе? Нехорошо будет, однако
>>

TK>Сообщение никто не проглотит. Другое дело, что таже java не может гарантировать, что сообщение о превышении температуры будет доставлено оператору например за 1сек максимум.
Согласен, в системе написаной на java такой гарантии нет.
А если система написана на NET такая гарантия появляется ?

С уважением,
AVM

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

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

R>>В таких задачах дотНЕТ действительно делать нечего.

IT>Ты забываешь, что в отличии от Java, .NET != C# и в нём есть место любым языкам. В частности C++, на котором написано всё о чём ты говоришь. Соответственно остаются все доступные методы отпимизации и пр.

Правильно ли я понимаю что программа написанная на VC++, будет работать абсолютно так же, как и программа написанная на C++ под NET ?
Или в NET вообще нет поддержки C++ ?

Спрашиваю не для флейма, а что бы понять что реально дает поддержка в net множества ЯП.

С уважением,
AVM

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

TK>>Сообщение никто не проглотит. Другое дело, что таже java не может гарантировать, что сообщение о превышении температуры будет доставлено оператору например за 1сек максимум.
AVM>Согласен, в системе написаной на java такой гарантии нет.
AVM>А если система написана на NET такая гарантия появляется ?

Нет. Так-же как и Windows не является OS реального времени.

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

AVM>Правильно ли я понимаю что программа написанная на VC++, будет работать абсолютно так же, как и программа написанная на C++ под NET ?
AVM>Или в NET вообще нет поддержки C++ ?

Поддержка С++ есть. Большинство программ написанных для C++ могут работать либо как обычно либо с минимальными переделками. На сайте MS есть рассказ про портирование Quake2 под .NET по описанию — это не заняло много времени.

AVM>Спрашиваю не для флейма, а что бы понять что реально дает поддержка в net множества ЯП.

Каждый язык имеет свою нишу.

• VB.NET или JScript.NET удобны в случае использования позднего связывания (работа с Automation клиентами и т.п.).
  
• С++ удобен для взаимодействия с native кодом — прозрачная работа с WinAPI вызовами.
  
• J# — дополнительные возможности от java библиотеки.

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

HN>>А почему не берем? RTS — это как я понял Real Time Strategy?

A>Real-Time System,

Перегулял на новый год

Что касается Real-Time System, то сообщение должно быть обработано за детерминированный отрезок времени. Для некоторых систем этот отрезок времени может быть достаточно большим. Так что опять же для некоторых RTS .NET вполне может подойти. Да и потом никто не гарантирует, что не выйдут какие-нибудь RTX for .NET от Venturcom и иже с ними