глянул на группу, аж на слезу прошибло :)

Зато программисты на Си-шарпе, если уж и находят работу, то зашибают сразу 100$/час =)

да.. на самом деле шарперов много, просто они все в группе .NET

не парицца! c# - самый респектный и прогрессивный язык! будущее за нами!!

кста, никому не нужен шарп-программер на работу? ))

Кто нибудь знает где можно найти книги в электронном виде по Mono? Буду очень признателен за ссылки.

Книг по Mono сейчас пока нет, к сожалению

а почему по Mono отдельные книжки?
Это все равно, что мне искать книжки по Java под Linux :)

потому что люди хотят знать чего нет в Mono и при этом не хотят читать документацию :)

Народ! Объясните как решить задачу о пяти философах на С#. Просто интересно - это делается так же как и на С++ с помощью семафоров или есть менее болезненные методы?

админ, мож картинку поставишь? яж тебе слал

Народ, у меня тут очень важный вопрос - по поводу нужности .NET и C#. Когда появилась эта чудо-технология, многие пророчили ее революционность и огромное распространение. Но я что-то не наблюдаю популярности ни C#, ни .NET в целом. Ну для Web конечно довольно часто используют ASP .NET, но приложений под винду что-то не видно. Мне очень нравиться C#, и мне хотелось бы узнать ваше мнение о складывающейся ситуации. У меня есть лишь одно объяснение - C# просто опередил время.

C# - жесть, иногда по привычки проще всё написать на С++, а потом добавить класс к С#. Язык вообще крутой, даже черезчур и некоторые темы в нём вообще непонятны, например таблицы dateGrinView, лучше б доделали старые таблицы, используемые в С++.

Это не язык тогда жесть, а платформа.. ибо API к языку не относится.

Но C# без .NET это вообще ничто. Ведь ечли ты пишешь на C#, это значит, что ты пишешь бод дотнет или под моно.

просто, если не нравится компонент из API - возьми другой, это все меняется..
к языку же претензия не относится

я написал, мало ли Александр этого не понимает.

Ну да. Впринципе можно использовать COM-объекты, даже WinAPI.

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

Да нет, все проще: не устраивает .NET-овский компонент? Берешь другой компонент, написанный под .NET. И все тебя прекрасно понимают.
COM, WinAPI нужно трогать тогда, когда уже других путей нет.
Хотя.. я жавер, у нас кроссплатформенность это важно. А вам это может и не критично.

Кажется, на Джаве, как-то и пофигу на кросплатформенность, как говориться "Что написано когда-то, то должно работать везде". Если есть машина написанная под определённую среду, то и приложение будет там работать.

Так-как приложение сразу конвертируется в байт код. С С# же проблема другая. Код храниться в специальном формате IL, кажется, в который входит код (что-то вроде асма) + исходник программы с описанием классов и методов (если конечно захочешь) + мета теги в которые прописывается доп. информация. Кажется так.
Программа же компилируется в двух зависимостях, проверятся какая ОСь стоит и какое используется оборудование, и в соответствии с этим происходит формирование машинного кода. Что ещё хорошо то, что не компилируется весь код, а компилируется только нужный в данный момент кусок. Минус в том, что на все проверки уходит время.

IL компилируется в байткод при сборке (как асм - в машинный код). Чистый IL можно получить, попросив комилятор не компилить "до конца", или дизассемблировав полученную сборку.
А уже потом, при выполнении, JIT транслирует байткод в машинный код конкретной платформы.

Кстати, в книжке "философия .NET" приведен пример на байсике и СиШ, которые, типа, в один байткод должны компилиться. После их листингов показывают два листинга IL, которые отличаются на 20%. И внизу приписка: "видны незначительные отличия в коде, обусловленные использованием различных языков". Т.е. писать-то можно на любых языках, но результат будет разным.

Не читал Филисософию .NET. Щас вот хочу почитать Рихтера, говорят, что грандиозная книжка.

Имею задание на курсовой проект сварганить файловый менеджер а-ля Тотал Коммандер.. какой-нибудь относительно простой. Буду признателен, если подкините парочку идей по тому как его лучше сделать! ;)

Раз пошла такая пьянка. А можно сделать конвертор ASM to IL-ASM?

ИМХО нет. MSIL слишком высокоуровневый. Это всеравно,что написать конвертер ASM to Си.

2Олег:
Сор за грубость, но или я тупой, или ты жжош. Что значит "IL компилируется в байткод при сборке"? Какой байткод? В сборке - код на IL и прочий трэш вроде манифеста и ресурсов. Компилятор (csc.exe) из исходника делает IL, JIT - из IL делает машинный код конкретной платформы.
Сам же ниже пишешь "в один байткод должны компилиться. После их листингов показывают два листинга IL"... Если ты IL называешь байткодом - непонятна первая фраза, если байткод - это нечто промежуточное - тогда непонятна вторая часть...

IL - это точно не байт код. Это что-то вроде ассемблера, я сказал бы.
И в машинный код он компилируется в зависимости от ОСи и установленного железа, каждый раз при запуске.

IL - это именно тот самый байт-код.

Source -> IL -> Bytecode -> Machine code

csc: Source -> Bytecode
JIT: Bytecode -> Machine code
disassembler: Bytecode -> IL
assembler: IL -> Bytecode
translator: Source -> IL
csc = translator + assembler

Стало понятней?

IL - это человекочитабельный байткод.

Аналогично тому, как язык ассемблера для невиртуальной машины - человекочитабельный машинный код. По сути, виртуальная машина - та же машина, что и пень-4. Тоже получает бинарное месево на входе и что-то с ним делает.

PS. В 4 пентиуме машинный код транслируется в микрокод, что похоже на то, как Джава или Джиттер делают со своим байткодом. Виртуальность даже в камнях, верить никому нельзя :-)

PPS. Ассемблер - это не язык, а "сборщик", тот кто из асм-инструкций собирает бинарник (подключает либы, расставляет адреса памяти, раскрывает макросы и т.д.)

"Язык ассемблера" - это и есть _язык_. Так его и называйте.

Да ну IL суть дела такой же объектно ориентированный, как и С# - и честно сходства с Асемблиром почти никакого...

Асемблер появился тогда, когда ещё никаких сборщиков не было и это был первый язык => неисчего было собирать - это сейчас всё компилят в асемблер, чтоб на лету транслировать в машинный код...

***ть! Ассемблер - это не язык. Ассемблер - это сборщик бинарника.

Сборка осуществляется по инструкциям:
1) мнемоническим кодам самих операций (которые будут в бинарнике)
2) макросам (язык Си - это продвинутый макрос, на самом деле)
3) дополнительным командам о расстановке адресов, линковке с либами и т.п.

IL для CLR (.NET Common Language Runtime) - такой же язык ассемблера, как и язык для микроконтроллеров PIC, как для x86, как для PDP-9, Flash MX, JRE и любой другой виртуальной или невиртуальной машины.

Языки эти отличаются только синтаксисом, но суть у них одна: рассказать сборщику, как получить бинарник. Точка.

Ассемблер - это транслятор, который команды языка ассемблера транслирует в машинные команды, т.е. по сути дела разновидность транслятора.

Ладно, ударились тут в словоблудие... Сборщик, язык, транслятор...
Вопрос конкретный: кто-нить знает, как заставить шарповый JSON-десериализатор хавать унаследованные объекты? То бишь я в параметр сервиса пишу тип родительского объекта, а передаю унаследованный. Он, скотина, болт бьет на все дополнительные проперти и оставляет чистый родительский объект. На асп.нет никто, сцуко, не отвечает...
Собсна, вопрос чисто академический, я вчера вручную свой написал =)

2 Михаил: потомушто информация о том, какие поля сериализовать лежит в типе, который ты указываешь. Ты указываешь базовый класс - получай базовые поля. Думаю, если бы сериализатор всегда сериализовывал то, что дали (как в руби, ха-ха!), то указывать тип не пришлось бы вообще.

Хм..., но от прокси на сервис SOAP-сериализованные объекты гоняются без проблем. То есть по сигнатуре метод принимает базовый класс и возвращает базовый, а по факту отличненько работает с унаследованными.
Мну кажецца, что это либо десериализатор тупо недописан, либо это как-то связано с безопасностью. Мол, вы с жаваскрипта дрянь какую передадите, мы ее во что-нить не то десериализуем, а потом все шишки на нас... Хотя там вроде предусмотрен способ его переопределить, но слишком многа букаф, ниасилил =)

И вообще, наройте кто-нить еще 15 человек - будем весь этот флуд в обсуждения прятать =)

Не знаю ни про какой нахъ JSON, для System.Xml.XmlSerializer контроль сериализации происходит с помощью атрибутов, типа XmlInclude, правда уже не помню кто за что... но унаследованные обжекты сериализовывал (у рутовой ноды появляется дополнительный атрибут отвечающий за имя наследника), а потом на Jave и c+ десериализовывал и наоборот (у нас проект жил в 3х версиях - .net, java и objective-c под макинтошами, извращение, но благо за это платили).

И ассемблер это язык черт подери. Специфичный для каждого процессора, делающий доступным возможность писать не в машинных кодах, а в человекопонятных командах, не стесняющих возможностей чипа. ЭТО ЯЗЫК В ПЕРВУЮ ОЧЕРЕДЬ! а далее, зная язык, можете написать компилер. или JIT. для тех кто в танке - посмотрите никсовую реализацию .NET (да, есть такая! и под гребаным маком даже работает =)) ). Там JIT-кодогенерация делается с помощью макросов, у которых семантика схожа с asm'ом target-процессора.
to Олег Андреев - для нативщеков сборщик бинарника - линкер, так что не гоните тут. для managed чуваков - сборщик бинарников - сам компилятор. или JIT кодогенератор, смотря что под бинарником подразумевать.

2Евгений:
JSON - это не xml, в том-то и проблема. Это строчка вида
{"Жопа":{"Руки":["Левая","Правая" ]}}...

JSON - это такая шняга специально для веба. Это валидный JS-код, который просто помещается в eval(), на выходе которого получается JS-хэш (или массив). JSON = JS Object Notation.
Парсить xml на стороне клиента - это неуважение к обладателям IE6 и 256 Mb RAM. Хотя, если инфы мало, то хоть в post-script размечайте :)

Ассемблер - это тот, кто прозводит сборку (to assemble = собирать). Как эту сборку осуществить говорит язык ассемблера. Для каждого сборщика - свой язык. Под каждую платформу - свой сборщик. Есть платформа x86, под нее есть несколько сборщиков. Есть платформа .NET CLR, под нее есть компиляторы (например, csc), в которых есть сборщики. Сначала СиШ транслируется в IL, который является языком для сборщика. Затем из IL собирается бинарник (с т.н. байт-кодом). Бинарник называется сборкой (assembly).

А JIT берёт сборку и транслирует байткод в машинные команды для железа. Проводя аналогии, JIT - это как камень Intel Pentium 4, в котором код бинарный код (который вылезает из JIT-а) транслируется в микрокод, который собственно и попадает на конвееры.

Язык ассемблера зависит от ассемблера. Знать надо платформу, ее архитектуру, затем сборщики (ассемблеры), а затем - язык этого сборщика, чтобы его запрограммировать. А Евгений предлагает действовать наоборот: выучить язык сборщика, а потом каким-то образом писать компилятор, забыв про сам сборщик и то, что язык НЕ для платформы, а для сборщика.

2Олег:
When you compile a Microsoft.NET language, the complier generates code written in the Microsoft Intermediate Language (MSIL). MSIL is a set of instructions that can quickly be translated into native code.

Взято отсюда http://www.dotnet-guide.com/jit.html

Теперь читаем медленно и вдумчиво. Никакого байткода и прочей херомантии. Сборка содержит IL и ничего другого. JIT делает из IL обычный exe-шник, только не весь разом, а по необходимости. В обычном exe-шнике лежат обычные команды вроде push, mov и прочих команд ассемблера, только не в текстовом виде, а в байтовом. Ассемблер как язык тупо преобразует текстовые push и mov в соответствующие им байты и пишет в exe. Это немного упрощенная схема (там всякие страницы, ресурсы и прочая внутренняя структура exe-хи), но никаких принципиальных отклонений вроде нет.
Все остальное (вроде микрокодов и конвейеров) вообще из другой степи.
Далее - про парсить xml на стороне клиента. А как по-твоему тогда AJAX работает (в частности этот сайт)? Кто там этот xml парсит как не клиент? И мой домашний комп как раз с IE6 и 256Mb на ура с этим справляется. Он десятком спутников управлять может, не то что 16Kb текста распарсить - это задача нулевой трудоемкости.

ВКонтакте грузит JSON. Поскольку у меня компьютер и так загружен управлением спутниками (2 Гб памяти + 1,5 Гб свопа = веб-сервер в режиме дебага, логгеры, три браузера, включая протекающий файерфокс (там campfire, нужен по работе), пять pdf-книг, гток, асько, скайп, фубар, в опере 20 табов, 5 консолей с 9999 строками скроллбэка и 999 колонками каждая, уже заполненные до упора, 5 окон SciTE по 5 табов).

В таких условиях от парсинга XML с помощью JS-библиотеки реально тошнит, не поверишь :-)

Насчет IL. Для очистки совести я открыл "Эндрю Троэлсен. C# и платформа .NET", 800 страниц довольно подробного описания дот-нета. Там написано, хоть и размазанно по всей первой главе, что сборка (assembly) в виде .dll или .exe - это байткод, т.е. бинарное представление IL-команд. JIT на ходу транслирует одни бинарные команды в другие (соответствующие железу).

Открываем википедию на CIL и видим:
"Languages which target the .NET Framework compile to CIL, which is assembled into bytecode."

Там же:
"Just-in-time compilation involves the byte-code being turned into code immediately executable by the CPU."

Язык ассемблера - это не только push и mov, но еще и макросы, метки, команды подключения либ. И в этом есть "принципиальное отклонение" от тупого маппинга "одна команда -> один/два байта". В этом и есть отличие байткода от самого IL.

А сам байткод - это не хиромантия, а ваш инструмент. А вы не только не знаете как он работает, так еще и ошибочно учите всех остальных.

Introduction to MSIL:
http://weblogs.asp.net/kennykerr/category/7140.aspx

И вообще, как можно доверять ресурсам по дот-нету, если сайт для девелоперов выглядит так?
http://defyallchallenges.com/

Тьфу ты, понял я наконец, что ты под байт-кодом подразумеваешь - бинарной представление IL. Так ясен хрен, что он там не в текстовом виде хранится - это и так очевидно. Возможно там даже какие-то преобразования делаются, а не просто тупой маппинг, но это не так существенно. Я бы не стал этот байт-код выделять в отдельную сущность.
Ровно то же самое касается и ассемблера - да, в exe-хе много всякой чуши помимо команд ассемблера, но по сути, для общего представления - это так. Да здравствует бритва Оккама!

Ну и напоследок поумничаю - парсинг JSON от парсинга XML все равно ничем не отличается - все это - представление дерева в виде строки и трудоемкость у них одинаковая. Более того, даже чистая HTML страничка парсится твоим браузером для создания DOM-модели, так что от AJAX'а твой менеджер спутников не напряжется больше, чем от открытия любого сайта.

Ладно, засим предлагаю святые войны объявить завершенными =))), и обсудить еще что-нибудь.

Интересно узнать, что еще называется байт-кодом :)

Нет, Миша, ты так и не вкурил, что такое машинный код и чем он отличается от языка сборщика. Это я к тому, что "в exe-хе много всякой чуши помимо команд ассемблера". Все ровно наоборот :)

А насчет JSON vs. XML уточняю: последний парсят либой, написанной на JS, а первый - на Си. Разница в скорости есть? Плюс, JS-либа, парсящая XML - это лишняя сотня килобайт и мозгоебство для программиста. Если eval работает проще и быстрее, а генератор данных рассчитан специально на JS-клиента, то какого лешего брать XML? Почему бы тогда не YAML (даже компактнее и файл, и либа)? Или, CVS/TVS? Или Pascal Records - еще более компактная и быстрая вещь в сравнении с XML? А?

На РИТ-2007 ребята из Яндекса (Надя Строганкова и Олег Оболенский) говорили, что XML/XSLT следует использовать, когда у вас зоопарк машин, платформ и библиотек и вам XML нужен, как общий язык общения между ними. В специальных случаях передачи данных XML почти всегда избыточен и неудобен. Не надо строить железные авианосцы, когда достаточно каяка из пластика!

Кстати, каково твое мнение об этом?

http://defyallchallenges.com/

Ассемблер x86 не имеет никакого отношения к CIL.
Assembler, assembly, assembled однокореные слова.
ildasm, ilasm имеют по ошибке такие имена.

Программа на язык ассемблера x86 компилируется в машинный код. Все, что говорил Олег про ассемблера это правда, если имеется ввиду ассемблера x86. Язык ассемблера x86 - это не просто тупой маппинг мнемоники ассемблера и пары байт. Да это и метки, и данные, и все остальное... Можно вспомнить ассемблеры MS, Borland, Flat - у них у всех разные языки! Как следствие всего этого - необратимость процесса компиляции. То есть не существует отображения из машинного кода в язык ассемблера. Есть только отображение из машинных кодов в мнемоники ассемблера. Чувствуете разницу? Мнемоники не текст программы на языке ассемблера. Дизассемблер - это фикция, а дизассемблер(ассемблер(x))!=x. Иными словами, машинный код не изоморфен языку ассемблера. И компиляция необратима.

Если попробовать продолжить эти рассуждения на .NET получаем бред. Заменяем машинный код на байт код, а язык ассемблера на CIL, и вроде перед нами все та же картина. Но где сказано, что CIL это ассемблер? Это просто аналогия и нельзя это мыслить иначе! Отображение между байт кодом и текстом программы на языке CIL обратимо с точностью до локальных имен переменных. Это значит, что можно считать их равными ilasm(ildasm(x))=x - не выдаст ошибок, проверьте!

Если не принять, что байт код и CIL две формы одного и того же можно спорить вечно, забавно, что без этого статья в wikipedia противоречива посмотрите на эти две строчки и найдите противоречия.

Languages which target the .NET Framework compile to CIL, which is assembled into bytecode.
Upon execution of a .NET assembly, its CIL is passed through the Common Language Runtime's JIT compiler to generate native code

Цикл статей Kenny Kerr ужасен, он создан для тупых американцев, которые вместо того, что бы подумать головой ищут ответ в гугле, думаю, что они прежде того, как поцеловать девушку гуглили "как целовать девушку". Если хотите разобраться в CIL и .NET, берите C#, пишите код, копилируйте его юзайте ildasm, правьте код и используйте ilasm. И читайте "Common Language Infrastructure (CLI ) - Partition III - CIL Instruction Set"
С помощью этого вы сможете, например, добавить свойство в класс делегата, что невозможно на C#.

Денис, почти всё правильно сказал.
Только вот "у них [x86 асмов] у всех разные языки! Как следствие всего этого - необратимость процесса компиляции." Уточняю: необратимость не из-за демократии, а из-за особенности языка сборщика. Язык сборщика необратим: метки теряют имена, когда их заменяют на адреса. Относительные адреса заменяются на абсолютные, макросы - разворачиваются и подставляются.

ilasm(ildasm(x)) == x только в том случае, если ты не пишешь на CIL-е. А пишешь на СиШ, например, который компилится в такой CIL, который взаимно-однозначно маппится в байткод.
Однако никто не запрещает забить на Сиш и писать сразу на CIL. Вот в этом случае, подозреваю я, байт-код не будет обратим в исходный CIL-код (пробелы, естессно, не в счет :-). Надеюсь, знатоки подтвердят это, или, наоборот, покажут, почему любой CIL-код всегда обратимо компилится в байткод. Если CIL-е есть макросы (не функции!), то компиляция необратима.

Вот и я говорю, что байт-код и CIL - две форм одного и того же. Хотя раньше, если честно, не особо над этим задумывался.

Насчет defyallchallenges.com - крыша у них едет. Стоит у меня этот бета-Оркас долбаный - валится постоянно. Причем не до конца, а так, ругнется, потормозит и предлагает отчет послать. Снова что-то попытаюсь сделать - снова валится... Достал уже...

Значит, Orcas вещь нестабильная - у Михаила валится постоянно, а у меня не разу не падал. Может дело в разных версиях? У меня CTP, а не бета.

Хмм. Скажу точнее - у мну тоже CTP (кста, что это значит??). Валится не совсем она сама, а что-то вроде IntelliSence, когда я редактирую xslt-ху - пишет ошибку что TypeResolver или что-то в этом роде ошиблось и тормозит, пока пытается решить эту проблему. После этого предлагает послать отчет и замолкает. Но когда я снова открываю тэг - снова та же ботва.
Когда воспроизведу где это валилось - напишу точнее.

Все наврал. Редактирую .aspx, валится TypeLibBuilder.exe... Причем не обязательно даже что-то писать - сам по себе регулярно выдает ошибку.

Кто-нибудь!!!
Помогите найти нормальную прогу для построения блок-схем
заранее мучос грасиас =)))

Enterprise Architect меня в свое время порадовал.

Ян, попробуй Visio от мелкомякого - это самый простой вариант. А так ,на мой, взгляд лучше CorelDraw - ничего лучше не придумано.

Михаил, тогда понятно, я просто с asp сейчас не работаю, пишу WinForm приложение и изучаю WPF - том не падало

Привет всем!
Кто может подсказать какие-нибудь библиотеки, которые позволяли бы разархивировать rar поток (не файл) также в один или несколько потоков (по количеству файлов). Очень надо.

unrar.dll не умеет работать со стримами? В самум худшем случае - исходники unrar доступны =)

УРА дотНЕТу

Люди, помогите, а?:) У меня есть контрол большой=) На него добавляю контрол поменьше. Как сделать background прозрачным настолько, чтобы видно было что нарисовано на большом контроле под мелким?)
Пишу на C# в VS2005. Если кто нить знает буду оч благодарен..

Даешь MONO! Графику через Gtk, среда разработки MonoDevel!)))
"Software is like sex, it's better when it's free" c Linus Torvalds

Линус торвальдс говоришь? Может ты сюда напишешь изречение еще какого-нибудь задрота типа Ричарда Столлмана?=)

mono - круто пока сырцы не глянешь. конкретно JIT. писали ребята старой закалки на си с плохой архитектурой, чтобы добавить какую-нить оптимизацию сырез на 600 строк аж по 4е человека пишут. а вроде части чуваков делающих ядро novell бабки платит )) open sux ))

Я тока взялся изучать C# и поетому может кто нить кинет ссылочку на хорошую справку по языку, ну или книженцию в електронке

msdn.com
лучше еще никто и ничего не придумал

2 Миша Кизилов
MSDN - да, но это скорее для кодинга. Мне в свое вермя нравился Шилдт - все кратко и по теме. Советую немного пописать классы в C++, а то многие вещи в СиШ будут неочевидны (сложно сказать какие, но только после С++ начинаешь понимать их). Потом надо хотя бы иметь представление о MVC или лучше MVP, Document-View, а то виндовы приложение новичков смахивают на кровавое мессиво.

Может подскажет как работать с Open Gl в C#?

пасиб за справку

Всем доброго здравия, господа! =)
Console.WriteLine("Hello, World");

http://www.exler.ru/novels/wife.htm - записки невесты программиста.

всем здрасти!!!!!!!!

Привет славным программерам!

Как говорит мой директор - нахрен все книги, у вас есть компьютер и гугл =)

Всем привет)

MessageBox.Show("rE oll");

Предлагаю логотип для группы

http://www.csharpdev.co.uk/Images/CSharp/Logo_Large.jpg

Привет самой продвинутой части программерства! :)
Хотелось бы наладить связь с людьми, реально увлекающимися шарпом. Пишите, отвечу ;)

> Может подскажет как работать с Open Gl в C#?
Либо через PInvoke, либо через Tao Framework. Тока лучше работай с DX, OpenGL это зло.

Привет! Тоже люблю С#. Правда в последнее время использую его исключительно в asp.net. Десктопных приложений не писала со времен учебы в универе.

Ну что, вы меня принимаете в свою компанию с такими условиями :)))?

2Диана Вишневецкая
Ну так на СиШ как правило и не пишут под десктоп:)

Смелое утверждение.

LOL

Теперь у нас есть "Обсуждения" - можно что-нибудь обсудить. ;-)

Диана, web-сервисы пишешь, или web-приложения?

Пишут на шарпе и под десктоп - www.posterjet.com - RIP-приложение с клиентом на шарпе =) и еще много примеров. Есть своя специфика написания эффективных програм на шарпе, а когда кодеры в нее не врубаются то говорят что шарп голимый, CLR голимый, микрософт голимый и т.д.

Так, нука быстро сосчитали скока у вас прог на компе, написанных под .NET и скока на C++ (WinAPI, MFC, COM и пр.). Есть еще вопросы?
А вообще C# программисты востребованы. И что же они по вашему пишут? Ответ: корпоративные приложения.

Угу в гробу видал этот asp.net. JSP/Servlet в JAVA в стократ удобнее. А десктопные приложения как раз на С# удобнее чем на Java

2Денис а сколько лет С+ и СиШ? ты погоди, скоро перевес в другую сторону будет. Тем более вышла Виста где CLR выведен в ядро системы. И к тому же MS заявита что WinAPI уже ими не поддрживается и он остается в винде только для совместимости. Так что это вопрос времени

2Денис. Не только корпоративные приложения - а еще всяки тулзы для себя на нем кодеры пишут. Мы щас вовсю, например, подымаем умирающий 3D проект, всякие вспомогательные херни и скрипты херачим на шарпе (и CLI/C++). Экономим время. WinAPI это хорошо, MFC - калич, COM - жесть. Взаимодействие C++/COM(in-proc) медленнее чем между классами из разных сборок. за .NET - будущее )) C# кодеры востребованы, но на хорошую ЗП востребованы программисты asm/C++/C# ))

Дмитрий Куранов > Угу в гробу видал этот asp.net. JSP/Servlet в JAVA в стократ удобнее. А десктопные приложения как раз на С# удобнее чем на Java

Сказано слишком радикально, но примерно верно.

Ребята, я достаточно долго уже программирую и прекрасно представляю что на чем пишут=) Конечно в будущем .NET скорее всего вытеснит COM, но будет это скорее всего не очень скоро. Я имею ввиду текущее состояние дел - сейчас на .NET писать под десктоп не выгодно, т.к. приложения будут не конкурентно способны. И не потому что там писать удобно или не удобно. Писать то удобно, только вот производительность низковата=). Особенно страдает GUI, в WinForms скорость реакции контроллов слишком уж низкая. Знакомые ребята, занимающиеся разработкой красивых интерфейсов пытались писать под .NET - лажа полная выходит, приходится писать на MFC, да это неудобно, но это эффективно.
А на счет ASP.NET и JSP, не знаю не писал, знаю ребят которые писали и на том и на том, говорят что будущее определенно за ASP.NET. Единственное, что могу сказать, есть такие вкусности как LINQ и ASP.NET AJAX.

А по поводу Vist-ы да, виртуальная машина запускается моментально, но опять же низкая скорость реакции котнтроллов(( Да и сама Vista по-видимому провальный проект, если бы все резко на нее перешли, то может у программистов поубавилось гемороя и они бы смогли писать больше десктопных приложений под .NET, а пока их ооочень мало. У меня вот на компе тока Paint .NET стоит из крупных прог на .NET.

2Иван : писал ис своего личного опыта
2Денис : незнаю у меня скорость контролов нормальная, у тебя машина какая? А десктопрные риложения написаные под CLR и под вистой и под ХР будут работать. Они также WPF под ХР подняли только в ХР нет Presentation Host и если приложение исрользует, WPF то оно будет тормозить под ХР(у меня тормозит только запуск).
Ктсати AJAX не зависит от того ,на чем написано серверное приложение, он просто определяет другой способ общения сервера и браузера. Так что AJAX есть и в JAVA,PHP,PERL...

2Дмитрий Куранов
Ну у меня тоже скорость нормальная, но все же заметно медленнее, чем unmanaged С++ (бибилиотеку Qt не в счет, такой же тормоз). И это тока если у тебя простой интерфейс. Как-то баловались компонентом для рисования диаграмм, так там каждая картинка секунд по 5 рендерится. Пока Vist-у еще рано брать в рассмотрение, а на счет WPF ты прав, запускается долго. Еще немного работал с WWF, под XP, JIT-ится када забускаешь работопоток порядка нескольких секунд даже на быстрых машинах. Так что будем ждать распространения Vist-ы и повышения производительности компьютеров, что бы можно было без угрызений совести писать под .NET для десктопа=).

Что такое AJAX я тоже хорошо себе представляю=) Просто в ASP.NET появился достаточно простой способ такой вот организации общения сервера и браузера. Я имел ввиду не уникальность, а простоту.
Потом из достоинств ASP.NET надо отметить сервер, под которым вся эта бадяга может работать - IIS7. Реально клевая вещь, там даже поддержка PHP есть.

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

Эти уже не детские болезни должен Orcas вылечить - на VS2005 меня дико бесила скорость меню, выполненного в стиле office 2003. В вижуалке - такое же, но оно летает, а тут - тормоз. На бетке оркаса проверял - реально оптимизнули )) Меня смущает неоптимальный ассемблерный код при сравнении float'ов =( кто-нибудь может по этому поводу что-нибудь сказать?