Has .NET removed the distinction between various languages?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 CLSCompliant attribute. 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.