4 ms·
I think the answer is: because Microsoft let it. I'm a big fan of modern .NET, but my biggest complaint is that Microsoft views, and always has, the CLR as the
by bmitc 3y ago
I think the answer is: because Microsoft let it. I'm a big fan of modern .NET, but my biggest complaint is that Microsoft views, and always has, the CLR as the C# Language Runtime and not the Common Language Runtime.
For example, see the relationship between F# and C#. The CLR is constantly getting features that are only to support features in C#, leaving F# in a position where they either don't get the feature, can't add the feature, or begrudgingly add the feature to keep up compatibility with C#, which is something it does take seriously. But this has the effect of "dirtying up" the F# language by either adding features that don't really belong in the language or keeping features out.
The other thing is that C# consistently adds features to itself that are inspired by F#, since F# already implements these features on the CLR, thus showing their viability. So what happens is that C# continually approaches a more bloated language with a subset of it being a poor copy of F#. But then F# gets dragged along towards having a small subset of C# in it for compatibility purposes. So it's simultaneously making both languages worse.
Even the iron languages project that lead to IronPython, IronRuby, etc. was a bit of a Trojan horse to test out and exercise the CLR and .NET with no intention of ever providing long-term support for those projects. The DLR, which was implemented to support those, appears to be just maintained by a skeleton crew of people invested in it, probably by those interested in keeping IronPython up and running.
I do not understand why Microsoft takes this approach. It is myopic, shows a misunderstanding of their own technology in the CLR, and ultimately turns C# into another C++, leave dead languages and projects in the wake.
- themerone 3y agoThe F# situation is not comparable to VB.NET. VB.NET was just C# semantics with a VB like syntax. From the beginning it didn't serve any purpose except to make VB Fans feel slightly more at home.
- bmitc 3y agoI think it's comparable in the sense of what I was pointing out: Microsoft only truly cares about C# and only keeps F# and VB.NET going just enough.
- nobodyandproud 3y agoInterestingly enough there are a small handful of things VB.NET and C++/CLI can do which C# can't, which enable the former languages to have better interoperability with COM interfaces. That was with .NET Framework and I'm not sure what the story is today with .NET Core aka .NET 5+.
- Guvante 3y agoThey eventually added optional names parameters which made the interop problem much better for C# compared to VB. C# wasn't as good still but you no longer had to put earlier params at their default value (which is what made it unusable). C++/CLI will probably remain king of interop though being a Frankenstein combination of the .NET runtime and C++.
- nobodyandproud 3y agoThe other headache was indexed properties, but I don't think that's changed. C++/CLI is no man's land and I tried my best to avoid it; and so far, I've managed; sometimes after-the-fact.
- Guvante 3y agoTo be fair VB.net originally had dynamic capabilities that C# lacked so at least it possessed features that made its existence justifiable. However the extreme changes required to go from VB6 -> VB.net made it all kind of moot, might as well rewrite.
- MichaelMoser123 3y ago>The other thing is that C# consistently adds features to itself that are inspired by F#, since F# already implements these features on the CLR, thus showing their viability. So what happens is that C# continually approaches a more bloated language with a subset of it being a poor copy of F# C# and F# sometimes remind me another pair of languages: Java and Scala.
- bmitc 3y agoF# started out as integrating much better and being very selective of features, whereas Scala has been happy to add all sorts of features, to my understanding. F# has been feature complete for a while, mainly getting quality of life improvements and updating to maintain C# compatibility.