4 ms·

I thought the exact purpose of the CLR was to be a general-purpose VM for arbitrary programming languages. I mean, it's even in the name: Common Language Runti

by Nelkins 10y ago

I thought the exact purpose of the CLR was to be a general-purpose VM for arbitrary programming languages. I mean, it's even in the name: Common Language Runtime. Also, there's this passage from the CLR docs (a.k.a. Book of the Runtime) that explicitly states its multi-language intentions[1]. [1] https://github.com/dotnet/coreclr/blob/master/Documentation/botr/intro-to-clr.md#multi-language-support https://github.com/dotnet/coreclr/blob/master/Documentation/...

iainmerrick 10y ago
Huh, the meaning of the name hadn't even occurred to me! I guess I just think of it as the Common Microsoft Language Runtime. :) It seems like alternate languages on the CLR have never really caught on, even though in principle it's more flexible than the JVM. The only ones you hear much about are C# and F#. Compare to the JVM where you have Java, Scala, Clojure, Kotlin. And neither the CLR nor JVM seems to have caught on for low-level, performance-critical code (game engines, scientific programming, deep learning). I guess people feel the garbage collection and bounds checking add too much overhead. So the new fashionable approach seems to be portable machine code, very close to the way real hardware behaves. If you want bounds checking and garbage collection, do it yourself.
- WorldMaker 10y ago
  I've seen the CLR used in low-level, performance-critical code. Performant game engines in XNA were better than a lot of critics gave them credit for. (Schizoid, a game nearly no one purchased, for one immediate example of a very performant game built in the CLR that didn't get enough credit.) The failures in XNA were more market segmentation failures (XBLIG versus XBLA, alone; though Schizoid and a few others passed through into XBLA) than engineering. With the UWP the market segmentation failures are disappearing, which is good for sales, but also means that successes in the CLR are less visible too: at a glance you can't tell if a UWP app is a CLR app or not. (Plus, .NET Native further blurs the lines.) In a different domain from games, there were some very interesting apps I've seen that were very low-level, performance-critical written for the IoT before IoT was a term space in the old Micro-CLR. I still of the opinion that a lot of the reason people don't use CLR/JVM and other runtimes more for low-level/performance-critical code has a lot less to do with "overhead" of garbage collection/bounds checking (whether it is as bad as critics often perceive it to be is another debate), and as much to do with stubbornness and job protection ("Of course my C and Assembly skills are still needed, because the CLR will never compete with my hand unrolled loops that are nearly impossible to debug and segfault the machine sometimes, which you should pay me to fix.").
  - iainmerrick 10y ago
    I think a big part of the problem with .NET is just that it's a big confusing mess of confusingly-named components. MS managed to take their own excellent technology and turn it into a legacy nightmare. Am I targeting C#, the CLR, the CLI, or making a PCL, or what? Which PCL profile(s)? It's way worse than Java in that respect and Java's already pretty bad (not that anyone uses J2ME much any more).
    - WorldMaker 10y ago
      Your comment doesn't seem particularly on topic, but a lot of the confusion you speak of seems to be your own. C# is a language, the CLR is the standard for a runtime (and typically the name of the classic .NET desktop runtime if not otherwise specified), CLI are command line interfaces, PCLs are now extinct and going the way of the dodo (replaced by the much more useful .NET Standards, of which .NET Standard 2.0 is probably the only one most people care about right now). Yes, there are plenty of acronyms to keep up with, but I'm not sure I would agree that .NET is any worse than Java (or really any other multi-language, multi-platform stack that has to support both the future and a good collection of backwards compatibility).

by Nelkins 10y ago

iainmerrick 10y ago

Huh, the meaning of the name hadn't even occurred to me! I guess I just think of it as the Common Microsoft Language Runtime. :) It seems like alternate languages on the CLR have never really caught on, even though in principle it's more flexible than the JVM. The only ones you hear much about are C# and F#. Compare to the JVM where you have Java, Scala, Clojure, Kotlin. And neither the CLR nor JVM seems to have caught on for low-level, performance-critical code (game engines, scientific programming, deep learning). I guess people feel the garbage collection and bounds checking add too much overhead. So the new fashionable approach seems to be portable machine code, very close to the way real hardware behaves. If you want bounds checking and garbage collection, do it yourself.

WorldMaker 10y ago
I've seen the CLR used in low-level, performance-critical code. Performant game engines in XNA were better than a lot of critics gave them credit for. (Schizoid, a game nearly no one purchased, for one immediate example of a very performant game built in the CLR that didn't get enough credit.) The failures in XNA were more market segmentation failures (XBLIG versus XBLA, alone; though Schizoid and a few others passed through into XBLA) than engineering. With the UWP the market segmentation failures are disappearing, which is good for sales, but also means that successes in the CLR are less visible too: at a glance you can't tell if a UWP app is a CLR app or not. (Plus, .NET Native further blurs the lines.) In a different domain from games, there were some very interesting apps I've seen that were very low-level, performance-critical written for the IoT before IoT was a term space in the old Micro-CLR. I still of the opinion that a lot of the reason people don't use CLR/JVM and other runtimes more for low-level/performance-critical code has a lot less to do with "overhead" of garbage collection/bounds checking (whether it is as bad as critics often perceive it to be is another debate), and as much to do with stubbornness and job protection ("Of course my C and Assembly skills are still needed, because the CLR will never compete with my hand unrolled loops that are nearly impossible to debug and segfault the machine sometimes, which you should pay me to fix.").
- iainmerrick 10y ago
  I think a big part of the problem with .NET is just that it's a big confusing mess of confusingly-named components. MS managed to take their own excellent technology and turn it into a legacy nightmare. Am I targeting C#, the CLR, the CLI, or making a PCL, or what? Which PCL profile(s)? It's way worse than Java in that respect and Java's already pretty bad (not that anyone uses J2ME much any more).
  - WorldMaker 10y ago
    Your comment doesn't seem particularly on topic, but a lot of the confusion you speak of seems to be your own. C# is a language, the CLR is the standard for a runtime (and typically the name of the classic .NET desktop runtime if not otherwise specified), CLI are command line interfaces, PCLs are now extinct and going the way of the dodo (replaced by the much more useful .NET Standards, of which .NET Standard 2.0 is probably the only one most people care about right now). Yes, there are plenty of acronyms to keep up with, but I'm not sure I would agree that .NET is any worse than Java (or really any other multi-language, multi-platform stack that has to support both the future and a good collection of backwards compatibility).