C# (программистское)

[avva]

Расскажите мне, пожалуйста, что вы думаете о C#/.NET и прочих смежных темах (в частности, Mono — если я захочу поиграться с C#, то, видимо, будут делать это в Линуксе под Mono). Насколько это хороший/чистый/многообещающий язык? А среда/CLR насколько хороши? Я ничего не знаю о них (C#/.NET сотоварищи), но достаточно хорошо знаю Java/C++/Perl/Smalltalk, так что сравнения с этими (или другими) языками приветствуются — равно как и любые другие мнения, в том числе пристрастные.

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

Comments

[(Anonymous)]

равно как и любые другие мнения, в том числе пристрастные.

C# сосет!

[dimrub.livejournal.com]

C# - ОЧЕНЬ похож на Джаву. ОЧЕНЬ. Из отличий - убрали, скажем, анонимные классы, заменив их конструкцией по имени delegates, добавили несколько примочек (properties = smart fields, indexers = smart arrays etc.), которые на первый взгляд казались лишними, но на поверку сильно облегчают жизнь.

Язык довольно чистый, немного чище, чем Джава (которая уже была довольно чистым языком).

Что ты подразумеваешь под средой?

.NET с точки зрения имеющихся APIs сильно напоминает J2EE, но лучше оного за счет:

1. Будучи более поздним изобретением, не наступает на те же грабли. Например, все, что нужно для работы с XML - уже внутри.

2. Нормальная security model, а не джавовское безумие, когда есть три модели: J2EE, JVM и операционки, и работают они как лебедь рак и щука.

3. Нет жуткого количества deprecated APIs, в которых тонешь поначалу.

Идеей CLR я не проникся. На кой хрен кому-то писать проект на пяти языках одновременно... Почему недостаточно было надстроить DCOM, чтобы совместимость была исключительно на уровне интерфейсов - не понимаю. Впрочем, я сейчас как раз работаю над проектом, где большая часть кода - на До-диез, а меньшая - на VB.NET, так что может и проникнусь.

Насчет хорошей книги - могу порекомендовать "Inside C#", сам ею пользуюсь. Она дает достаточно полное введение в CLR и в C#, но, к сожалению, не покрывает .Net Framework.

Да, тебе, возможно, будет любопытно почитать про ASP.NET. Лично у меня впечатление, что это воплощение wet dreams всех веб-программистов. Посильнее Гете Фауста вещица! Не понял пока, правда, как на ней писать scalable web applications, но если можно - это писк.

[alickop.livejournal.com]

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

Не желая обидеть, просто забавно: что-то типа этого (http://www.ozon.ru/context/detail/name/book_catalog/id/942529/)?
А что касабельно субъективного мнения о С-шарп, так от лукавого это все.

[msh.livejournal.com]

У меня опыт небольшой - я прочел книжку по C# и написал какую-то мелочь именно с целью ознакомиться

На мой взгляд, ничего интересного. C# - это "java лучше чем java", улучшено заметно относительно java, но не настолько, чтобы было интересно смотреть. Если припрет программировать на C# - можно, для удовольствия - вряд ли.

[dei-os.livejournal.com]

1. С# очень похож на Java.
2. С# очень хорош, в том смысле, что очень много есть технологий в Java, которые требуют поиска и осмысления (нужны ли они, поддерживаютися ли и т.д.), чего не нужно в изделиях майскрософт. (они просто есть, причем волне неплохи)
3. документация в Java намного лучше, чем в С#. (Javadoc - forever!:)))
4. Mono - (к сожалению, приходилось работать) во многих вопросах сильно недоработанная штуковина. хотя, в принципе, надежды есть.

Кратенько так...

[(Anonymous)]

Яву в свое время изучать не стал - потому что это было самое начало и она не очень понравилась некоторыми своими предложениями. Поэтому сравнения провести не смогу.

Далее буду говорить и о .NET, и о C#, потому что C# - это базовый язык для .NET (VB.NET тоже базовый, но по-другому)

1) .NET - это будущее разработки под Windows. Факт, который можно даже не обсуждать.


2) На .NET можно писать все приложения под Windows (кроме драйверов).

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

Конечно, отличия есть: в веб-приложениях нет GUI-окон, но можно пользоваться классами рисования (есть пример, где ASP-страничка генерирует и возвращает картинку).

Но коллекции (массивы, списки), работа с файлами, работа с многопоточностью - она везде одинаковая.


3) Безумная безопасность.

Пример: по-умолчанию, система настроена таким образом, что доступ к файлам возможен только для программ, которые запускаются с локального диска. Как только запускаешь этот же ".exe" с сетевого диска, так сразу же возникают исключения (exceptions).

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


4) Remoting

Жестокая штука (не знаю, как переводится на русский).

Разрабатываешь приложение - оно работает локально. Потом изменяешь определенные настройки в конфиг-файле, после чегообъекты указанных класов начинают создаваться не локально, а удаленно. Причем взаимодействие происходит через сериализацию поверх TCP или HTTP. Естественно, подобную возможность надо закладывать в приложение изначально (поддерживать сериализацию, делать компоненты, ...)


5) Огромадная библиотека классов

Согласно легендам, в .NET около 3,800 классов. Есть его родные классы, есть просто обертки вокруг каких-нибудь Windows-функций/COM-серверов.

Основная сложность - это не просто 3,800 классов, сваленных в одну кучу, а очень тесно взаимодействующих между собой.

Например: можно разработать свой компонент (и продавать его), который в самой Visual Studio будет выглядеть как родной. Он будет вытаскиваться и бросаться на формы или другие компоненты, у него будут свои редакторы свойств и так далее.

Другой пример: в оконном приложении можно связать контрол (edit-box) и какую-либо переменную - система автоматически будет отображать или обновлять значения (из переменной в контрол и из контрола в переменную).

Найти подобные связи - занятие не для слабонервных.

Там есть классы для генерации кода. Просто создаются объекты типа "условие", "выражение", ..., потом они объединяются и либо вызывается генератор на каком-нибудь языке (C#/VB.NET точно есть, остальные - не знаю), либо компилируются в код для виртуальной машины, который можно практически сразу же выполнить.


6) Отладка

Это сказка. Есть большой проект, он весь модульный и все такое. В отладчике можно ходить-бродить по этим модулям взад-вперед, как хочется.
Удобные средства логирования: написал код с логированием, посмотрел его в отладчике, а в релизе продукта указал, что логирование производится "вот в этот файл".


7) Reflection

Любой класс/структура сохраняется с описанием - какие поля, функции, какие типы, видимости элементов и так далее. Более того, к этой информации можно получить доступ во время выполнения программы.

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

Кстати, о плагинах - если разрабатывается приложение с поддержкой плагинов, то их можно ограничивать по безопасности. С коде основного приложения так и писать - "в доступе к файловой системе отказать, в доступе к сети отказать", а плагину предоставить свои (приложения) методы для получения необходимой информации.


................

Re: Кратенько так...

[(Anonymous)]

8) Непрост в изучении/использовании

И хотя все эти вкусности выглядят невероятными (или смешными - кому как), у них есть несколько минусов.

Оно требует достаточно серьезной подготовки, как в теоретическом, так и в практическом плане. Те, кто просто запускает VS.NET, создает приложение, вытаскивает на форму две кнопки и прямо в обработчиках нажатия на эти кнопки начинает выполнять нехилые действия, тех людей ожидает разочарование.

Будет очень полезно продумать архитектуру приложения еще до начала его кодирования. Потому что именно в .NET появилась возможность (для меня, по крайней мере) разработки компонентных приложений.

Пример: сидел я и на работе игрался - делал веб-сервис для доступа к Ораклиной базе. И что-то оно у меня не работало - где-то падало, где-то ошибку возвращало. Долго я думал, очень долго. А потом вдруг прояснилось и я всю работу с базой вынес в отдельную библиотеку, каковую и стал использовать и в веб-сервисе, и в обычном оконном приложении-тесте. Одна библиотека - один код. Многоуровневые приложения становятся реальностью.

Но знать здесь надо очень и очень много. Потому что то же самое простое вынесение сразу же подняло вопрос "как узнать, кто меня выполняет". Для оконного приложения и для веб-сервиса это можно определяться и инициироваться по-разному.


9) C# и прочие языки под .NET

Язык чудесный. После долгих мытарств на C++ очень радуюсь, что он есть. Писать на нем просто, не надо заморачивать себе голову вопросами, которые не являются важными при разработке обычных приложений.

Еще есть так называемый Managed C++ - это когда код на C++ компилируется под .NET. Использовать этот режим крайне не рекомендую. Слишком велика разница между просто C++ и самой платформой .NET. Когда наблюдаешь эту разницу в двух разных языках (C++ и C#), то все нормально. Но если видишь один C++ в обоих ипостасях, то можно запутаться даже в базовых конструкциях...

************

В общем еще можно рассказывать много-много. Из-за своей громадности и эдакой всеобъемности одной книги по нему не хватит. А разных книг не очень много.

Рекомендую прочитать Рихтера - кое-что рассказано хорошо. Но одного его точно не хватит.

Еще можно читать MSDN Lib и MSDN Magazine - там есть много как вводных статей, так и достаточно хитрых (как можно реализовать AOP).

***********
рома

Re: Кратенько так...

[avva.livejournal.com]

Большое спасибо!

Всего один вопрос ещё мне неясен: насколько медленне исполняются скомпилированные аппликации на C# по сравнению с обычным C++? Если я правильно понимаю, они компилируются всегда под виртуальную машину, но с каким-то мощным оптимизатором, напоминающим джавовский just-in-time compiling? Или есть компиляция в non-secure native code?

Если планируется переход всего в Windows, включая большую часть самой OS, под C#/.NET, значит ли это очередной резкий скачок в сторону замедления и потери performance, который "съест" выигрыш в скорости процессоров, памяти итп. за эти несколько следующих лет?

Re: Кратенько так...

[lnvp.livejournal.com]

В продолжение вышесказанного хотел бы обратить внимание на .NET как на среду для компиляторных/рантаймовых экспериментов — лучшую, чем Java/JavaVM. Например, благодаря включению соответствующих средств в стандартные библиотеки, полнофункциональный компилятор с подмножества C укладывается в 3000 строк. Ещё пример: несколько лет назад Дон Сайм реализовал поддержку generics в CLR - теперь она входит в состав .NET 2.0 (другую его разработку по расширениям для функциональных языков, похоже, не взяли).
Вот ещё одна любопытная разработка - статическая верификация аннотированного программного кода на уровне CLR.

Re: Кратенько так...

[lnvp.livejournal.com]

Потеря производительности зависит, как обычно, от того, какая программа - на некоторых специальных примерах можно наблюдать выигрыш (например, за счёт отложенного возврата "свободной" памяти и логики сборщика мусора, обеспечивающей кучность часто используемых данных). Любимый пример пропагандистов - Quake II .NET бегающий почти так же, как native.

IL никогда не интерпретируется, перед выполнением код всегда прогоняется через JIT. Можно заранее предкомпилировать IL в native.

То есть, есть надежда, что скачок всё таки будет не слишком резким :^)

Re: Кратенько так...

[(Anonymous)]

В свое время провел очень и очень простой опыт - реализовал поиск простых чисел (перебор с делением до половины самого числа).

Искались простые числа от 1 до 100,000.

На VC++ 6.0 программа выполнялась 12.5 секунды, а на C# - 13.2.

Согласно оценкам MS потери по скорости составляют до 30% (если я правильно помню).

Весь код живет на дисках в виде кода для виртуальной машины. Но перед выполнением он компилируется в код реального процессора. То есть, интерпретации подвергаются незначительные (или значительные - как приложение написано) части кода. В .NET есть три модели такой компиляции - перед первым вызовом функции, при загрузке кода в память (по-умолчанию) и хранение откомпилированного кода в системных папках (может производиться при установке ПО).

Однозначно, если вызывать функции DLL или обычные COM-сервера, то снижение производительности может быть критическим (потому что каждый вызов ведет к преобразованию - marshalling - параметров, которые выполняет сам .NET).

Один из минусов .NET - требования к оперативной памяти. Минимальное оконное приложение сразу же кушает от 12 до 16 Мб оперативной памяти.

Но эти минусы (память и процессор) легко компенсируются удобством и сравнительной легкостью разработки на .NET. По крайней мере, именно на нем я начал тратить 90% времени на реализацию своих идей, а не на борьбу с неясностями в C++/COM/....

О резком скачке - не думаю, что так получится. Просто на .NET можно реализовывать другие алгоритмы работы, которые на обычном C++ (или чем-нибудь другом) реализовывать либо сложно, либо не очень хочется. Да и сам код на нем проще получается.

Например, согласно некоторым предположениям в блогах самих микрософтовцев, если для работы с сетью на VB 6.0 надо было написать около 60 Кб кода, на VB.NET уже около 10-30, то на будущих библиотеках это занимает в пределах 1 Кб (числа помню смутно, но порядок приблизительно такой). Так считают те, кто участвует в разработке этих самых библиотек :)

P.S. По крайней мере, мои исполняемые файлы превысили 100 Кб (для сложного приложения) лишь когда я начал добавлять в них ресурсы-картинки :):)

***********
рома

Re: Кратенько так...

[(Anonymous)]

Хочу отметить еще одну вещь.

Многопоточность и распределенность являются родными и неотъемлимыми частями .NET.

Когда был DOS, жизнь была более-менее простой. Потом появился Windows и жизнь усложнилась - и памяти вдруг могло не хватить, и работа с графикой стала более забавной.

А вот .NET ставит многопоточность и распределенность на одну ступеньку с GDI и файловой системой.

И это очень непросто - спроектировать и реализовать приложение, которое будет нормально работать в условиях, когда файлы берутся неизвестно откуда, когда некоторые объекты могут жить на другом компьютере, а вызовы их методов ничем не отличаются от работы с локальными объектами (с синтаксической точки зрения)...

**********
рома

[ex-sgt783.livejournal.com]

Как и было сказано, это Ява с некоторым количеством улучшений по спорным вопросам (enums, properties итд). ASP.NET, соответственно - J2EE.

Совершенно не рекомендую пробовать левые имплементации типа Mono. Чем .NET качественно отличается от Java/J2EE, так это единой (понятное дело) и крайне удобной средой разработки - VS.NET. С визуальной поддержкой всего на свете - в т. ч. очень удобно работать с веб-сервисами, на что как раз особенно напирал их маркетинг, и с чем у явы по сей день очень по-разному.

А так ничего нового, конечно.

[ex-sgt783.livejournal.com]

Насчет ASP.NET - я не очень сильно вдавался в ее подробности, но на неглубокий взгляд не смог найти там 10 качественных отличий от J2EE. За исключением разве что интерфейсных веб-компонентов - то, что в народе кличут Java Server Faces - но эта штука не показалась особо рррреволюционной.

А на самом деле?

Этот вопрос как никогда продемонстрировал...

[shtraz.livejournal.com]

...полезность анонимусов :)))

От себя добавлю:

1) Для Вас может не слишком актуально, но для мира Windows эта платформа станет, похоже, реальностью уже года через 2. Вы знаете, что Microsoft планирует заменить api на .NET, и нынешний апи будет эмулироваться примерно как когда-то эмулировался 16-битный апи для совместимости? А планы Microsoft на счет NET грандиозны: Yukon (новый SQL сервер) на .NET уже почти здесь. Причем очень заманчивые перспективы открывает в этом случае как раз CLR: для Юкона свои функции (эквивалент UDF (User's Defined Functions)) можно писать на любом языке поддерживающем "писанину" для CLR - это ответ на вопрос про то "кто же будет писать проект на нескольких языках?" А вот Вам пожалуйста - у нас теперь есть унифицированный интерфейс на порядок облегчающий написание плагинов и UDF.

2) Авва, если Вы поддадитесь этому соблазну (а для меня например .NET пока серьезной НЕОБХОДИМОСТИ не представляет), отпишите потом нам о совместимости программ под .NET написаных в Windows и Linux. А то шуму-то много на этот счет, а вот услышать о результатах из первых уст...

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

4) Я бы посоветовал почитать Рихтера (могу выложить в электронном виде (AppliedNet.pdf)).

5) Я-то согласен с Ромой высказавшемся выше, но хотелось бы еще слышать противников .NET. Хотя я все равно уже .NET.

Re:

[(Anonymous)]

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


Кто-нибудь может рекомендовать нормальную книжку по Ява? Не такую, где "вызовите эту функцию для того, а вот вам пример кода на 20 страниц...", а по основам, по языку, по самой платформе?


*sgt* абсолютно прав - в .NET нет ничего нового. Все элементы .NET существовали уже начиная с 70х годов (виртуальные машины, объектность, ...), но вот собрать их в такой удачной и удобной пропорции еще никому не удавалось.


*************

Я в Яве не разбираюсь, но никогда не слышал, чтобы в ней можно было вызывать функции из DLL. Или использовать существующие COM-сервера.

А .NET предоставляет очень сильную поддержку существующего кода (вызовы DLL и COM). Более того, на .NET можно делать обычные COM-сервера.

.NET - он, в общем, предназначен для Windows. Слишком много вещей берутся именно из него, а не реализуются в библиотеках самого .NET.

*************

Поддержка "enum" мне очень нравится. Их можно чудесно преобразовывать в строки и обратно (стандартными методами).

А вот скоро, когда-нибудь, будет .NET 2.0 и C# 2.0. Анонимные методы - это непросто. Особенно с их доступом к локальным переменным метода, в котором они объявлены.

*************

Есть легенда, что в свое время MS ислледовала концептуальное программирование (или программирование в ограничениях). Более того, они собирались воплотить это в жизнь. Возможно, многое в .NET растет именно из этой области.

********
рома

Re:

[nine_k]

> На кой хрен кому-то писать проект на пяти языках одновременно

а если есть legacy code на C++ или java, и переписывать его (пока) очень не хочется?

> Почему недостаточно было надстроить DCOM

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

Re: Кратенько так...

[malaya-zemlya.livejournal.com]

К сожалению, Quake 2 уже не является мерилом производительности. Современные графические карты уже способны нарисовать *весь* кваковский уровень вообще безо всякой оптимизации. То что остается - простой AI и интерфейс - особенно процессор не нагружает. Проверять надо по современным играм, типа Doom3 и HL2 . Там процессор под завязку загружен физикой, навернутым AI, сложными графическими алгоритмами и т.п.

Могу заверить, во всех современных играх "крупного калибра" фундамент до сих пор пишется на С/С++/Ассемблере. Если другие языки и используются, то только для скриптов, задания сценариев и прочих навесок.

Исключение составляют игра для мобильников - те пишутся часто на Яве. Там переносимость важнее скорости.

Re: Кратенько так...

[(Anonymous)]

полнофункциональный компилятор с подмножества C - oxymoron

Re: Кратенько так...

[lnvp.livejournal.com]

Не буду спорить, хотя по мне — нормальная программа для тестирования производительности (хардверная акселерация графики, конечно, отключена). Идея была в том, чтобы взять достаточно навороченную программу на C++ и скомпилировать под .NET, потом сравнить скорости выполнения. Пропаганда, я же сказал. И никто под .NET ресурсоёмкие игрушки писать не собирается (пока :^) )

(Кстати, писать для PC-шных процессоров последних поколений на ассемблере ручками — ещё более неблагодарное занятие, чем когда бы то ни было; под логику спекулятивных вычислений и прочее всё же лучше код компилятором оптимизировать. Интересно, пишут ли ещё на ассемблере код для DSP...)

Re: Кратенько так...

[lnvp.livejournal.com]

Давайте, давайте, придирайтесь к словам - ник влом завести, да?

Re: Кратенько так...

[(Anonymous)]

Я к словам не придираюсь. Пустое, хотя и полнофункциональное, подмножество С можно реализаовать на C++ в одну строку.

> ник влом завести, да?

Я ничего без необходимости не завожу. Я вам и так скажу все, что вы хотите знать обо мне.

Re: Кратенько так...

[lnvp.livejournal.com]

На самом деле мне вспомнился язычок - подмножество C#, а не С под названием C flat. Извините, я тоже не вижу смысла в дальнейшем общении с анонимом (как и не испытываю интереса к вашим данным).

[avva.livejournal.com]

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

[bobuk.livejournal.com]

Я не знаю чем людям не нравится Mono.
Неплохая реализация машины. По крайней мере майкрософтовский mcs.exe под ней запускается и работает :)
Ссылки на учебники по C# есть на сайте Mono.