народ, а как насчет С#

Пробывал, игрался. 50 метров весит.
Форма теперь полностью в xml-подобном виде. (XAML)
Чтобы создавать нормальные формы, нужно приобретать (отдельно) Редактор Blend.

Если запускать на XP, то у некоторых людей форма с 1 контролом грузиться по 15 секунд. У меня 5.
В Висте будет быстрее.

 

apple

Респект мелкомягким!
этож как постараться нужно было... умеют!
)))

надеюсь, оно при этом и оптимизированно под многоядерные процессоры!!! )))
и на мощном серваке с 8-10 ядрами за секунду будет отрисовываться!))))))))))))

 

UMan
Та ладно, это ещё мелочи. Вот установка 1 сервиспака к VS 2005, занимающая 2-4 часа и 2-3 гига места (при том, что сама студия ставится мин. за 15-20 и влазит в 2 гига) — вот это уже клиника.

 

Для меня самым ярким примером, демонстрацией, и образцом вооплощения мощности технологии .Net (насчет применимости C# - в этом образце, я не в курсе), стала оболочка для администраторов, с громким именем "Microsoft PowerShell" (во времена, когда я ее тестировал, она называлась так-же Monad). Что это такое? Гибкая, мощная навороченная замена стандартному интерпретатору комманд (cmd). С одним, как мне показалось существенным недостатком: комманды dir, cd, выполняются секунд за 5, а то и дольше, и это на мощной машине.

 

Установочные требования: свободных 6,1 GB на системном(!) разделе.

 

alpet
Это перебор. Недостаток перекрывает все достоинства А вообще - посмотрите на популярные шеллы - на чём они написаны? GTK, KDE? Отнюдь. Они написаны на чистом си. И это не зря - ведь они должны работать максимально быстро, "dir, cd" - это же основные "кирпичики", из них строят более комплексные скрипты. Сколько же будет занимать по времени более-менее серьёзный скрипт? Посему, cmd+cscript останутся наиболее применимыми для администраторов Windows®.

 

IceStudent
Сейчас большая часть задержек устраненна, но все внешние комманды (консольные приложения), вызываются гораздо дольше, чем в привычном cmd. Ну и сама оболочка грузится порядка 3-4 сек (первый инстанс). Хотя, тем кто без автоматизации жить не может, наверное не сочтет это слишком уж большим недостатком. Все это тем не менее, не оправданно (изучать новое изобретение MS, без веской причины), даже из-за того что связка порта sh/bash или WinGW (у меня есть такое дело) + Perl / PHP, в коммандной строке позволят творить чудеса (опять же опыт скрипт-кодинга нужен). А "заматеревшие" админы, наверняка довольствуются VBScript (меня от его нестабильности, в дрожь бросает - помню мелкомягкий скрипт испытывал, по работе с правами файлов - ужас одним словом).
Подход технологии .Net, по отношению к "управляемому" коду, в плане производительности еще несколько лет будет оставаться ниже уровня Native Compilation (тут собственно язык, уже не такую большую роль играет - хоть с Delphi можно сравнивать). Особенно, это будет заметно при портировании проектов, написанных на C++, или по привычки пишушихся с оптимизацией, вроде:

Код (Text):

1. int nCount = list.GetCount();
2. for (int n = 0; n < nCount; n ++)
3. {
4.   if (list[n] == someVal) return n;
5. }

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

Код (Text):

1. for (int y = list.Count () - 1; y > 0; y --)
2. for (int x = 0; x < y - 1; x ++)
3.  if (list [x] > list [x + 1]) list.Swap (x, x + 1);

 

А че вам не устраивает скорость работы .net приложений версии 1.0 - 2.0? JIT как жит, скомпилирует дибильный IL в native, а там и работать программа начнет. Конечно можно у себя ngen'ом сгенерить машинный образ программы в хэш, и тогда прога юыстрее будет работать.

А вот Framework.NET 3.0 это уродство. Надо же такое XAML (ЗАМЛ, отродье XML'a) используется для построения формы (контролов). Этж надо же придумать: XAML помещается как Meta-data (помойму), и уж точно форма собирается на лету, тоесть IL+XAML = HTML+JAVA Во только Framework.NET дает ну оч много по сровнению с Java. А вооще тупасть с XAML, его нужно в IL переводить во время компиляции, а не пихать куда попало, а потом налиту собирать! Да и еще им стоит сделать IL в реальный native и сразу в фаил, а не помещать образ в хэш.

 

Это не недостаток C#, это недостаток Intermediate Language (промежуточный язык) при первом запуске программы JIT (Just In Time) переводит в native, а там уже программа начнет выполняться. Любой язык полностью или частично написанный под .NET, переводится на IL, так что не важно на каком языке ты програмируешь(не касаясь C++.NET - он позволяет смешивать Managed + Unmanaged) результат один и тот же. Это вам не Ассемблер где можно одно и тоже зделать разными путями, в IL все строго.

 

как только появился VS2003 и дотнет - мс потеряла моё уважение, а после того как я установил себе VS2005 в надежде на лучшее, понял, что дотнет - х...я редкая. 250 метров одних сборок! 2 гб на установку! мс потеряла совесть! (если конечно имела её)

 

Вот с этим я согласен на Framework.NET 3.0

Framework.NET 2.0 ~129 метров.

Ну а если уж место экономить, то можно VS2005 Express Edition [C++.NET/ C#/ VB.NET/ JAVA#] каждый по отдельность качать нужно. Каждый из VS ~150 - ~350 метров. А можно ваще извращаться Delphi.NET установить

 

Я тут недавно нашел в диспетчере задач тулзу, что потребляла всего 700кб памяти. Сильно удивился. Оказывается этой мой старый дельфийский прог, что выполняет лишь функцию Sleep. Наверное в будушем так просто не получится. Один манифесты мегабайт двести занимать будут...

 

Скажем дружно - нафиг нужно!

Вот убейся не понимаю нафиг писать под .net то, что элементарно пишется на плюсах с использованием API. Мода типа ? Мелкомягкие завтра всем скажут вешаться и вы пойдёте ?

.net - ничто иное как попытка упростить и ускорить процесс "программирования" ценой потери скорости и качества конечного программного продукта. Конечно за всё надо платить, но не в таком же объёме...

 

Ты .net 3.0 видел с блендером? Все движется к PowerPoint =)

 

Ms_Rem, неужели ты воскрес, а сколько слез было пролито..

 

roman_pro

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

Для сравнимости по первым 3м показателям, квалификация С++-программиста должна быть значительно выже, чем С#-, что ведёт к проигрышу по п. 4.

Что поделать...

 

Нет, просто (с) на фразу не знал чей.

 

Согласен. Скорость падает, однако рост производительности современных процессоров тоже о чем-то говорит...

А здесь не согласен. Программы, написанные под .net, гораздо стабильнее.

 

Ну и скажи: много ты встречал компов с athlon fx62 или core 2 duo extreme?
Если не в курсе: такую аппаратуру берут либо геймеры с безразмерным кошельком родителей либо народ, которому надо повыпендриваться перед друзьями(девушкой).

Кстати, игр на .net я ещё не видел. Наверное, эта одна из передовых отраслей компьютерной промышленности никак не приемлет .net, опасаясь за непомерно возростущие системные требования для современных игр.

Сказки.
Может быть на висте, где .net уже встоен (хотя, как я уже говорил - х...я редкая), такие проги будут работать стабильнее. А на XP, которую юзают большинство пользователей продукции мелкомягких, установка .net и работа с ним добавляет только проблем, а не стабильности.

ВЫВОД: дотнет - MUSTDIE!

 

Borland очень много кричала о Delphi, но была вынуждена её продать...
Microsoft очень много кричала, что все будут писать только на Java, но и её послали на...
тоже произойдёт и с .NET'ом, потому что качественные оптимизированные алгоритмы всегда были в цене. Драйверы пишут на чистом C, но с ассемблерными вставками. И врядли это когда-нибудь изменится, потому как ассемблер ближе всех к машинным кодам, т.е. он - наилучший способ общаться с процессором после машинных кодов. Ну а машинные коды заменить чем-либо было бы крайне нерационально...
==

==(из сборника "Все законы Мерфи".)