Убрал ли .NET различие между различными языками?

Question

У нас всегда были языки, которые предпочтительнее использовать в определенном сценарии. Для быстрой разработки прототипа VB6 был очевидным выбором. VB6 был выбран в проектах, которые имели простой пользовательский интерфейс рабочего стола и стандартные и несложные требования к взаимодействию с базой данных. Если вы хотели разработать драйвер устройства с использованием низкоуровневых подпрограмм, вы, вероятно, полагались на C или Visual C ++. ASP был стандартным выбором для разработки веб-интерфейсов. Каждый язык имел определенный «домен» или «специализацию», говоря грубо.

С платформой .NET все языки совместимы и предположительно согласованы. У вас может быть проект с модулями из разных языков, но все они в конечном итоге обрабатываются одинаково (все компилируются в IL).

Значит ли это, что различие, которое мы имели ранее, больше не существует? Это различие не обязательно было плохим, скорее, оно было разработано и не связано с какими-либо ограничениями. Это, по-видимому, несколько уменьшено с помощью .NET Framework и его обработки различных языков.

Answer 1

Различия все еще существуют. Например, VB.NET в настоящее время поддерживает позднюю привязку IDispatch лучше, чем C # (исключая C # 4.0), а VB.NET имеет литералы XML, встроенные в код, что делает его удобным инструментом для манипуляции XML по сравнению с другими языками .NET. C ++, как правило, не очень хорошо подходит для .NET, даже с вариантом C ++ / CLI, но он отлично подходит для нативного программирования (как всегда) и для обеспечения уровня взаимодействия между управляемым и неуправляемым кодом.

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

Answer 2

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

Тем не менее, большое преимущество .Net, и это, возможно, вдохновило вопрос, состоит в том, что вы можете использовать объектный код языка 1 в библиотеке, написанной на языке 2, связанной приложением, написанным на языке 3.

Давным-давно, до появления электричества и автомобилей, вы не могли просто использовать сгенерированные C файлы .obj в приложении на Pascal или Delphi (и наоборот) без явной упаковки их в DLL (и заботы вызывающего метода, последовательности параметров и совместимости параметров) или обращения к другому исполняемому файлу.

Answer 3

Нет, это не имеет возможности фреймворка не такие же, как языковые функции. Сказать, что .Net убрал различие между языками, это то же самое, что сказать, что в коде ассемблера убрано различие между языками.

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

Answer 4

Во всяком случае, я думаю, что усилило различие между языками, в точности , потому что они настолько совместимы. В центре внимания сейчас находится язык .

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

Например, для работы с COM с поздней привязкой я мог бы (неохотно) выбрать VB (или я мог бы ждать C # 4.0). Для некоторых конкретных финансовых / симуляционных работ я мог бы серьезно подумать о F #. Для обычного бизнес-программирования я выбрал бы C #.

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

Answer 5

Я думаю, что это действительно зависит от контекста, из которого задается вопрос.

Допустим, вы разрабатываете библиотеку для пользователей. Вы помечаете эту сборку атрибутом CLSCompliant. Это означает, что компилятор заставит вас использовать функции, гарантированные CLR, и не сможет скомпилироваться, если вы используете функцию, специфичную для языка.

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

Теперь предположим, что вы пишете свою библиотеку на VB .NET и решили использовать необязательные параметры, а не перегрузку методов. В этом случае .NET выделяет различие между языками, потому что необязательные параметры не совместимы с CLS (хотя C #, очевидно, поддерживает их в .NET 4.0.) Для тех, кто использует язык, который не поддерживает необязательные параметры, ваша библиотека может быть невозможно или в лучшем случае сложно использовать. Каждый язык имеет несколько функций, которые не совместимы с CLS, при их использовании пользователям некоторых языков .NET будет труднее использовать ваши библиотеки.

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