.NET 是否消除了各种语言之间的区别？
我们总是有更适合在特定场景中使用的语言。 对于快速原型开发，VB6 是一个显而易见的选择。 在具有简单桌面用户界面和标准且不复杂的数据库交互要求的项目中选择了VB6。 如果您想使用低级例程开发设备驱动程序，您可能会依赖 C 或 Visual C++。 ASP 是 Web 界面开发的标准选择。 粗略地说，每种语言都有一个特定的“领域”或“专业化”。
借助 .NET 框架，所有语言都可以互操作并且大概是一致的。 您可以拥有一个包含来自不同语言的模块的项目，但最终所有模块的处理方式都相当相似（所有模块都编译为 IL）。
这是否意味着我们之前的区别不再存在了？ 这种差异化并不一定是坏事，而是有意为之的，而不是由于任何限制。 显然，随着 .NET 框架及其对各种语言的处理，这种情况有所减弱。
We have always had languages that were preferable to be used in a particular scenario. For a quick prototype development, VB6 was an obvious choice. VB6 was chosen in projects that had a simple desktop user interface and standard and un-complicated database interaction requirements. If you wanted to develop a device driver using low-level routines, you probably relied on C or Visual C++. ASP was a standard choice for development of web interfaces. Every language had a particular 'domain' or 'specialization', speaking crudely.
With .NET framework, all languages are interoperable and presumably consistent. You can have a project with modules from different languages all together but all ultimately being treated fairly similarly (all get compiled to IL).
Does this mean that the distinction we had earlier no longer exists? That differentiation was not necessarily bad rather something that was there by design and not due to any constraint. That apparently is diminished somewhat with the .NET framework and its treatment of various languages.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
区别仍然存在。 例如，VB.NET 目前以比 C#（不包括 C# 4.0）更好的方式支持 IDispatch 后期绑定，并且 VB.NET 具有与代码内联的 XML 文字，这使其成为与其他 .NET 语言相比操作 XML 的便捷工具。 C++ 往往不太适合 .NET，即使有 C++/CLI 变体，但它非常适合本机编程（一如既往）以及在托管和非托管代码之间提供互操作层。
每种语言的语法都有细微差别，可以更轻松地表达某些概念。 即使它们都归结为 IL，也与以前都归结为汇编时没有什么不同。 您可以选择最能支持您尝试执行的任务的语法的语言，无论它编译到哪个平台。
The distinctions still exist. For example, VB.NET currently supports IDispatch late-binding in a nicer fashion than C# (excluding C# 4.0) and VB.NET has XML literals inline with the code which makes it a handy tool for manipulating XML compared with other .NET languages. C++ tends to not be so well suited to .NET, even with the C++/CLI variant, but it is excellent for native programming (as always) and for providing an interop layer between managed and unmanaged code.
Every language has nuances in its syntax that make it easier to express certain concepts. Even if they all boil down to IL it's no different than before when they all boiled down to assembly. You choose the language with the syntax that best supports the task you're trying to do, regardless of the platform it compiles to.
语言差异仍然存在。 将语言编译为汇编代码还是 MSIL 并没有真正的区别，只是 MSIL 的抽象级别可能高于汇编代码。
不过，.Net 的一大优势（这可能引发了这个问题）是，您可以在用语言 2 编写的库中使用语言 1 的目标代码，该库由用语言 3 编写的应用程序链接。
很久以前，在没有电之前和汽车，您不能简单地在 Pascal 或 Delphi 应用程序中使用 C 生成的 .obj 文件（反之亦然），而不将它们显式包装在 DLL 中（并注意调用方法和参数序列以及参数兼容性） ，或调用另一个可执行文件。
The language distinctions remain. It does not really make a difference whether you compile a language to assembly code or MSIL, except that maybe the abstraction level of MSIL is higher than that of assembly.
The big advantage of .Net though, and this may have inspired the question, is that you can use object code of language 1 in a library written in language 2 linked by an application written in language 3.
Long time ago, before there was electricity and auto-mobiles, you couldn't simply use C-generated .obj files in a Pascal or Delphi application (and vice versa) without explicitly wrapping them in a DLL (and taking care of the calling method and parameter sequence and parameter compatibility), or calling out to another executable.
不，框架的功能与语言功能不同。 说 .Net 消除了语言之间的区别就像说汇编代码消除了语言之间的区别一样。
语言仍然有不同的特性，某些语言的语法更适合解决某些问题，否则整个 .Net 框架将在单一语言上同质化。
No it hasn't the features of the framework are not the same as language features. To say has .Net Removed the distinction between languages is like saying has Assembly code removed the distinction between languages.
The languages still have different features, the syntax for some languages is better at solving some problems, otherwise the entire .Net framework would homogenise on a single language.
如果有的话，我认为它可能增强了语言之间的区别，正是因为它们是如此具有互操作性。 现在的焦点是语言。
事实上，可以使用相同的基础服务和基类，这意味着您可以根据语言提供的内容（而不是与该语言合作的框架提供的内容）对语言做出明智的决定。
例如，为了使用后期绑定的 COM，我可能（不情愿地）选择 VB（或者我可能会等待 C# 4.0）。 对于一些特定的金融/模拟工作，我可能会认真考虑 F#。 对于常规业务编程，我不折不扣的选择是 C#。
但是您可以根据适合不同块的语言做出这些选择，并将不同语言的不同 dll 编织在一起完成的应用程序。 以前，您可能不得不与部分代码作斗争，因为您必须使用语言x来使其与其余代码进行互操作。
If anything, I think it may have heightened the distinction between languages, precisely because they are so interoperable. The focus now being on the language.
The fact that the same fundamental services and base classes are available means that you can make a sensible decision about the language based on what the language offers, rather than what the framework partnered to the language offers.
For example, for working with late-bound COM, I might (grudgingly) choose VB (or I might wait for C# 4.0). For some specific financial/simulation work, I might think seriously about F#. For regular business programming my out-and-out choice would be C#.
But you can make these choices based on the language suitable for different blocks, and knit the completed app together from the different dlls in different languages. Previously you might have had to fight with part of the code, because you have to use language x to get it to interoperate with the rest of the code.
我认为这实际上取决于提出问题的背景。
假设您正在开发一个库供客户使用。 您可以使用
CLSCompliant属性来标记此程序集。 这意味着编译器将强制您使用 CLR 保证的功能，并且如果您使用特定于语言的功能，则编译失败。当考虑使用符合 CLS 的库时，.NET 消除了语言之间的区别。 每种 .NET 语言都必须符合 CLS，因此保证您平等地支持每种 .NET 语言。
现在，假设您正在 VB .NET 中编写库，并且决定使用可选参数而不是方法重载。 在这种情况下，.NET 强调了语言之间的区别，因为可选参数不符合 CLS（尽管 C# 在 .NET 4.0 中显然支持它们。）对于使用不支持可选参数的语言的人来说，您的库可能是不可能或最多很难使用。 每种语言都有一些不符合 CLS 的功能，使用这些功能可能会使某些 .NET 语言的用户更难使用您的库。
所以，我觉得这是一个棘手的问题。 如果您正在编写符合 CLS 的代码，那么 .NET 语言之间只有语法差异。 如果不是，那么您可能会编写某些 .NET 语言无法使用的方法。
I think it really depends on the context from which the question is asked.
Let's say you're developing a library for customers to use. You mark this assembly with the
CLSCompliantattribute. This means that the compiler is going to force you to use features that are guaranteed by the CLR, and fail to compile if you use a language-specific feature.When a CLS-compliant library is being considered, .NET removes the distinction between languages. Every .NET language must be CLS-compliant, so you're guaranteed to support every .NET language equally.
Now, suppose you're writing your library in VB .NET and you decide to use optional parameters rather than method overloading. In this case, .NET is highlighting the distinction between languages because optional parameters are not CLS-compliant (though C# is supporting them in .NET 4.0 apparently.) For someone using a language that doesn't support optional parameters, your library might be impossible or at best difficult to use. Each language has a few features that aren't CLS-compliant, when these are used you are going to possibly make it harder for users of some .NET languages to consume your libraries.
So, I feel like it's a trick question. If you're writing CLS-compliant code then there's only syntax differences between .NET languages. If you're not, then you can possibly write methods that cannot be used by some .NET languages.