Идея данной заметки родилась при чтении многочисленных обсуждений «Какой язык из .NET лучше использовать или начать изучать».

Сам автор по роду своей деятельности сталкивался с достаточно большим количеством языков. Некоторые вызывали приятные ощущение, некоторые вызывали сильное неприятие. Программисты – все люди, разные, со своими пристрастиями и предпочтениями. Кроме того разные задачи требуют разных языков – в одном случае может быть использован алгоритмический язык типа С++, для других – функциональные языки (автор не сталкивался с такими, но идеология таких языков по моему мнению очень подходит к некоторым задачам).
Поэтому хотелось бы заострить внимание программистов, которые еще в процессе выбора языка, на следующей идее:
«Каждая задача, кроме того, что имеет всегда не одно решение, такое решение может быть реализовано на нескольких языках программирования»

В принципе взаимодействие разных языков уже существует не один год. Все мы вызываем библиотечные функции, подгружаем динамические библиотеки, в которые мы передаем какие-то параметры и получаем оттуда ответы. Для вызова такого рода функций нам необходимо только правильно передать данные в функцию и правильно интерпретировать ответ. Более поздний вид взаимодействия – Common Object Model (COM/DCOM). Здесь та же ситуация. Вы могли писать на разных языках и даже определять свои типы. Надо было только объяснить, как работать с этим типом клиенту и серверу.

Как видите самое важное – ЭТО ДОГОВОРИТСЯ О ТИПАХ.

Так вот, .NET предлагает ту же идею, только работать можно не просто с числами и строками. В рамках CLR (Смотри заметку «Что такое .NET») Вы можете работать с более сложными типами, которые являются уже классами и объектами.
Все возможные варианты записи типов определяются Common Type System (CTS) – «Общей системой типов». Данная система является системой типов, в рамках которой работает MSIL (Смотри заметку «Что такое .NET»). Т.е. MSIL поддерживает CTS в полном объеме. Если Вы научитесь работать напрямую с MSIL, то Вам будет доступен полный объем всех вариантов определения типов данных.

Автор позволит себе небольшой экскурс в CTS. Итак, CTS определяет все возможные варианты описания типов данных. У каждого класса может быть описано 0 и более членов, которые могут быть следующие:
Поле – описывает какую-то часть состояния объекта
Метод – функция, которая определяет какое-то поведение объекта
Свойство – для вызывающей стороны это кажется полем, но для вызываемой стороны есть возможность проверить какие-либо условия, т.к. это для нее вызов метода.
Событие – обеспечивает механизм уведомлений объектов.

Кроме этого CTS определяет правила для видимости объектов и доступа к их членам. Т.е. не всем и не всегда можно получить доступ к объекту и к его членам. CTS определяет следующие варианты доступа:
Закрытый – метод может быть вызван только внутри самого типа. (Для C# это private)
Родовой – метод может быть вызван внутри класса и всеми производными классами (Для C# это protected)
Сборочный – метод может быть вызван каким угодно объектом внутри одной сборки. О сборках мы погорим в другой раз. Пока думайте о сборке как об одном проекте на Visual Studio. (Для C# это internal)
Открытый – метод доступен любому коду из любой сборки. (Для C# это public)
Родовой или сборочный – метод может быть вызван любым кодом из той же сборки и любым производным типом (наследником) из любой сборки. (Для C# это protected internal)
Родовой и сборочный – метод может быть вызван ТОЛЬКО производным типом и ТОЛЬКО в той же сборке. И вот почему я поставил этот вариант в конце. В C# нет такого модификатора.

Как видите, даже такой приличный язык, как C#, не может обеспечить полное соответствие CTS. Visual Basic еще беднее: у него, например, нет системы перегрузки операторов, которая есть в C#. Что же говорить о (IMHO) еще более простых языках, для которых, тем не менее, уже сделаны компиляторы для .NET (Fortran, Perl, Python).

Оказывается, что Microsoft определила как максимально возможный набор типов (CTS), так и минимальный набор типов, который обеспечит взаимодействие разных языков – Common Language Specification (CLS) «Общая языковая спецификация».

Таким образом, для того, чтобы обеспечить взаимодействие модулей на разных языках внутри Вашего проекта необходимо, чтобы все Ваши модули создавали описания типов в соответствии с CLS. В этом случае Вам гарантируется, что все Ваши модули будут прекрасно взаимодействовать между собой. Полный набор тех правил, которым Вы должны следовать в этом случае, приведен в MSDN – «Cross-Language Interoperability».
Например, для того же C# существует специальная опция, которая будучи установлена, дает команду компилятору проверять совместимость описания типов со спецификацией CLS. Если Ваше описание совместимо с CLS, то с Вашей библиотекой сможет взаимодействовать любое другое приложение под .NET написанное на ЛЮБОМ другом языке. Если нет – Вы получите предупреждение. Такое предупреждение говорит только о том, что Вашей библиотекой не смогут воспользоваться модули, написанные на других языках. Если Вас вполне устраивает какой-либо один язык, то Вы можете использовать его, не обращая внимания на такое предупреждение.

Т.к. CLS это минимальный набор, то практически все языки для .NET не только поддерживают данную спецификацию, но и несколько расширяют ее. Само собой расширение не может выходить за рамки CST.

Если графически показать отношение между CTS, CLS и языками под .NET, то получится приблизительно вот такая картинка (можно посмотреть в самом низу)

Читатель наверно подумал «Ну так и что? Где же ответ на мой вопрос о выборе языка?»
На этот вопрос мне представляется самым разумным ответить следующим образом:
- Исходите из требования Вашей задачи. Кроме Вас самих никто не сможет лучше решить, на каком языке выполнять приложение. Наверняка у Вас есть какие-то предпочтения. Скорее всего в Вашей команде работают разные люди и все они предпочитают разные языки. Автор знает немало очень приличных программистов, которые работают на Visual Basic и создают очень высокопрофессиональные приложения. Тем более, что если рассматривать приложения клиент-сервер, например, для складского учета, то в такого рода задачах клиент является достаточно простым приложением, для которого в 95% случаев вполне достаточно использовать набор библиотечных компонентов, которые предоставляет .NET.
Если же Вы только начинаете изучение .NET, то мой совет – посмотрите все языки. Их там ведь не так уж много – Basic, C# и J#. Для просмотра спецификации языка достаточно максимум недели. Потратьте месяц на ознакомление, а потом начинайте изучать тот язык, который больше всего Вам нравится.

Как Вы сами скорее всего догадались, библиотека классов для .NET отвечает требования CLS и может быть использована в программах на любом языке.

Присоединённый файл ( Кол-во скачиваний: 287 )
 CLR.JPG

Цитата

Закрытый – метод может быть вызван только внутри самого типа. (Для C# это public

наверняка Антон имел ввиду не public а private

Цитата

Кроме этого CTS определяет правила для видимости объектов и доступа к их членам.

стоит отметить что все модификаторы, указанные Антоном могут быть применены не только к членам типа, но и к самому типу

Цитата

Родовой и сборочный – метод может быть вызван ТОЛЬКО производным типом и ТОЛЬКО в той же сборке. И вот почему я поставил этот вариант в конце. В C# нет такого модификатора

тут вопрос такой: если у класса нет модификатора internal, то можно ли его методы вызывать вне сборки? по-видимому такой модификатор просто не нужен

Цитата

Родовой –..... (Для C# это protected)

protected также часть переводится как защищенный, также internal логичнее переводить как внешний,доступный извне и так далее, так как перевод сборочный подразумевает использование только внутри сборки

Статья интересная, но могу предложить свой ответ
.NET идеология, абстагирующаяся от конкретного языка, на котором написано приложение, и в конечном счете не важно на чем вы будете создавать свой проект, в результате все рабно получиться код на CIL для CLR, это по-моему лишь дело вкуса, но писать на С# все же предпочтительнее, так как это язык разработанный специально для .NET и в наибольшей мере поддерживающий все фишки этой платформы

А какая наилучшая книга по .NET? Хочу начать изучать именно этот язык.

.Net - Это всего лишь технология от Майкрософт .Основными языками .Net считаются VB.Net,C#,C++.Net

Цитата

.Net - Это всего лишь технология от Майкрософт .Основными языками .Net считаются VB.Net,C#,C++.Net

+

Цитата

Если же Вы только начинаете изучение .NET, то мой совет – посмотрите все языки. Их там ведь не так уж много – Basic, C# и J#.

Ничего не понимаю! Дак в итоге сколько всего языков в Visual Studio .NET?

Ну, вот смотри..
M$ создала технологию .NET. ТЕХНОГОГИЯ не зависит от ЯП, главное - получить IL-код.
Поэтому, теоретически, ЯП неважен.
Итак, M$ предоставила несколько языков (в стандартную поставку входят C#.NET, VB.NET, Managed C++, JScript.NET).
Остальное - в свободном полете. Народ пытается сделать реализации более чем 30 языков (Pascal, Prolog и т.д.).
Поэтому, точно ответить, скока существует .NET-языков нельзя.
Ну, а в студии тоже - что поставишь, что и будет.
Конкретно, в VS2003 по-молчанию входят:
C#, VB.NET, J#.NET, VC++.NET.

..Я слышал, разрабатывают даже этакий VB на РУССКОМ языке - т.е. типа 1C.NET.

Kurt, спасибо, теперь ясно! Еще один идиотский вопрос: ведь JScript.NET и J#.NET явно не одно и то же, тогда, что такое этот самый JScript.NET - очередная реализация Java Script? Но его будет поддерживать тока винда с .NET Framework'ом, то есть писать на JScript.NET будет бессмысленно для сайта, хостящегося например на FreeBSD, я правильно понимаю?
Не очень понятно также зачем народ пытается реализовать еще больше языков, им что этого не достаточно? Особенно, на мой взгяд, не в тему будет реализация почти мертвого(по крайней мере на родине самого Microsoft'а) Pascal'я и уж тем более руссифицированного VB:) Хочешь общаться? - Научись разговаривать на более менее стандартизированном языке...

Цитата

Но его будет поддерживать тока винда с .NET Framework'ом, то есть писать на JScript.NET будет бессмысленно для сайта, хостящегося например на FreeBSD, я правильно понимаю?

Нет-нет. Ты немного не понял.
Еще раз как все происходит:
1) Ты пишешь прогу на любом .NET-языке.
2) С помощью компилятора переводишь текст проги в IL-код (промежуточный, кроссплатформенный код).
3) Среда выполнения (.NET-Framework или mono под Linux/Unix) берет этот IL-код, докомпиливает его с учетом данной ОС и с учетом конкретных ресурсов компьютера-исполнителя.
4) Докомпиленный код запускается на выполнение.

Итак, отсюда выводы:
1) Понятие бессмысленности написания на конкретном языке пропадает. Главное, чтоб у ТЕБЯ был компилятор. Ведь все это все равно переводится в один и тот же IL-код (ну, с небольшими несущественными различиями) - конечный итог работы .NET-программера.
2) Зачем куча языков? Это сделано для того, чтобы в одной команде могли работать разработчики, пришедшие из самых разных языков. Т.е. если я работал на С++, то я перейду на Managed C++.NET - они родственнки, а ты работал, например, на VB - тогда ты переходишь на VB.NET. А в итоге мы можем работать над одним и тем же проектом... Ну, а те, кто еще ничего не учил раньше, выбирает, что кому подуше.
3)

Цитата

будет бессмысленно для сайта, хостящегося например на FreeBSD, я правильно понимаю?

Как тебе сказать.. Поидее вся эта штука кросплатформенна. Единственное условие - наличие на компе-исполнителе виртуальной машины. На данный момент, такая поддержка есть в Windows и, частично, в Linux (mono). Конкретно, уже есть .NET-модуль для Apache 2.0, планируется выпуск модуля для Apache 1.3.
По поводу остальных ОСей - как только проект на Linux достаточно "окрепнет" - он будет перенесен под другие клоны Unix'a, а также MacOS etc. - так заявляют разрабочики.

Очень интересно... Просто слушал бы тебя весь вечер! Вот чего я еще не могу понять: коль скоро наша программа была Just-In-Time скомпилированна в момент ее запуска, получается, что в следующий раз она уже не должна будет компилироваться, а значит запуститься гараздо быстрее, то есть выполняться будет уже как любая другая обычная программа содержащая непосредственно команды процессора? Или я опять не прав? А если прав, то немного непонятно, что происходит с нашим .NET exe-шником в момент первого запуска: промежуточный байт код, хранящийся до этого момента в нем непосредственно заменяется на результат компилирования или этот результат перенаправляется в другой файл, а старый с байт кодом уничтожается???

Мы все больше и больше уходим от темы.
Я думаю, такие вопросы лучше задавать в разделе "Что же такое .NET ?"...

Цитата

Вот чего я еще не могу понять: коль скоро наша программа была Just-In-Time скомпилированна в момент ее запуска, получается, что в следующий раз она уже не должна будет компилироваться, а значит запуститься гараздо быстрее, то есть выполняться будет уже как любая другая обычная программа содержащая непосредственно команды процессора?

Да, гораздо быстрее. Однако, пока производительность .NET-приложений все равно уступает "обычным" программам. Я думаю, это связано с плохой оптимизацией JIT, однако, вроде, разработки в этом направлении ведутся, и, по заверениям M$, можно ожидать, что .NET-проги будут быстрее, чем обычные - ведь .NET-приложения оптимизируются непосредственно перед ВЫПОЛНЕНИЕМ на компе непосредственного ПОЛЬЗОВАТЕЛЯ, а обычные проги - на компе программиста.

Цитата

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

Нет, ну ты сам подумай, а если я потом захочу эту прогу с одного компа перенести на другой? Мне опять обращаться к непосредственному "источнику" (где я брал эту прогу) и опять копировать? А если я уже отдал этот диск? Этож какая зависимость от создателя проги!
Не-е-е-ет, тут чуток не так:
прога находится в оперативной памяти, кэшируется.
И при след. запуске минуется этап компиляции и берется уже готовый native-код, понятный CPU.
Ессно, если ты перегрузишься, то придется заново юзать JIT.

З.Ы.
1) как я уже говорил, мне кажется, такие вопросы лучше постить в разделе "Что же такое .NET?"
2) предлагаю зарегестрироваться - мы всегда рады новым юзерам.

Ну, все, Kurt, спасибо, тепрь точно пока все От темы больше отходить не буду.

Статья от Microsoft о Visual C++ .NET
C++: The Most Powerful Language for .NET Framework Programming

Скажите, пожалуйста(те кто здесь "по роду своей деятельности" сталкивался c .NET), от заказчиков ПО поступают какие-либо требования, на каком именно языке требуется реализовать программу? Если да, то на каком чаще?

Мое ЛИЧНОЕ мнение:
заказчику пофиг на чем будет реализована задача. Хоть на ASM, хоть на VB, хоть на .NET - лишь бы это было сделано вовремя, а также программа удовлетворяла параметрам системы (скорость работы etc.).
Поэтому тут нельзя говорить, какой язык нужнее.
В фирмах же, к-е занимаются разработкой софта, обычно четко указан ЯП - для "совместимости" с уже существующей командой разработчиков, а также при всяких лицензионных ограничениях (ну не хочет фирма платить деньги за VS - вот и требует от всех зание, скажем, Perl'a).
Однако, как я понимаю, сама Microsoft позиционирует C# как основной язык .NET-платформы. Поэтому, у многих работодателей слово "C#" ассоциируется с .NET, поэтому из .NET-языков чаще требуют С#.
С другой стороны, исходя из идеалогии .NET, язык не слишком важен - ведь все так или иначе компилится в IL-код.
Резюме: без разницы, однако все-таки стоит чуть больше внимания уделить именно C#, т.к. он позиционируется как основной язык самим производителем.

А чем принципиально отличается С++ от С#?