3 ms·

JVM wasn't originally intended to support multiple languages. IIRC, Sun wasn't welcoming to new languages on the JVM (Java Virtual Machine). But CLR stands for

JVM wasn't originally intended to support multiple languages. IIRC, Sun wasn't welcoming to new languages on the JVM (Java Virtual Machine). But CLR stands for Common Language Runtime and had three official languages shortly after release (VB.NET, C# and J#, offhand). In fairness, both Sun and Microsoft advertised what they were shooting for in the name.

orthoxerox 3y ago
Microsoft planned to support all kinds of languages and the list of CLR languages is respectably long, but most of them can't really keep up with the co-evolution of .NET and C#. The generics in .NET 2.0 were the first big compatibility break, and I think async/await was the second and even bigger one that killed off the bulk of alt-langs.
- WorldMaker 3y ago
  async/await was never a compatibility break at the CLR level. Most of async/await is "just" the TPL (Task Parallel Library), a subset of the .NET BCL (Base Class Library) and entirely handled as libraries, which any language can use/interact with even without async/await language support. The async/await language support in C# is basically a Monad transformer, building a generator-like asynchronous state machine. (The output of an async/await function in C# is rather similar in concept/implementation to the output of a generator function using yield syntax.) This is also why F# has never had a tough time with async/await because it has even more generic Monad transformer support ("computation expressions"). Any "alt-lang" could make use of the TPL whether or not they could transform their own similar syntax, and there's nothing stopping them from building a similar syntax. As far as I saw that wasn't a killer of languages.
  - orthoxerox 3y ago
    It wasn't a break at the CLR level, but it was a break at the BCL level. To consume the new async methods your language had to come up with a mechanism that was broadly similar to how C# worked or miss out on the vast majority of libraries and the BCL itself.
    - WorldMaker 3y ago
      If a language didn't do anything at all like C# it dealt with a lot of task.ContinueWith(value => {}) callbacks (Action<T>), no different to JS promise.then(value => {}) chaining (truly, no different at all because Task/Promise are basically twins). At worst case you had callback "waterfalls" to deal with, but that was hardly "breaking" and shouldn't have "killed" languages. async/await is much nicer than callbacks/callback waterfalls, but that doesn't mean you can't write callbacks/callback waterfalls (a lot of JS projects certainly did; many still do even despite most browsers supporting async/await today).
      - orthoxerox 3y ago
        The language would also need to have some support for anonymous delegates and closures, or its callback waterfalls would have to be broken up into multiple methods that would have to manage the call state themselves. CLS really expected most languages to look a lot of like early C#, that is, Java with some Delphi/VB features grafted on.
chubot 3y ago
> But CLR stands for Common Language Runtime and had three official languages shortly after release (VB.NET, C# and J#, offhand). CLR is not really common -- the "tells" are VB.NET and PowerShell. VB6 was a very popular and useful language, and VB.NET broke everything in that ecosystem, turning it into a variant of C# with different syntax. Does that sound like a multi-language VM? If so, why not compile VB6 to it? PowerShell is likewise best described as C# with a horrible shell-like syntax. It's not really a shell in the original sense, because it doesn't talk to the kernel directly -- it runs on a VM, which mediates all access to the kernel. fork() is a syscall that shells rely on critically, which is problematic for almost all VMs. Some notes on "interior" (VM-based) vs "exterior" (OS kernel-based) shells here: https://www.oilshell.org/blog/2023/06/ysh-design.html https://www.oilshell.org/blog/2023/06/ysh-design.html
- mmcdermott 3y ago
  It was intended to be common whether or not it succeeded. Those examples point to a differing design philosophy at Microsoft rather than some inability to write a language on the CLR. The design philosophy was clearly to do Java-ish typing across the board, supplanting VB6's loose typing and bash's text based mindset. I don't really like the approach. I think shell scripting succeeds because it allows ad-hoc programming and I don't think Java-ish weak but static typing is some perfect ideal to be used everywhere, but you could certainly implement a more loosely typed language on the CLR.

orthoxerox 3y ago

Microsoft planned to support all kinds of languages and the list of CLR languages is respectably long, but most of them can't really keep up with the co-evolution of .NET and C#. The generics in .NET 2.0 were the first big compatibility break, and I think async/await was the second and even bigger one that killed off the bulk of alt-langs.

WorldMaker 3y ago
async/await was never a compatibility break at the CLR level. Most of async/await is "just" the TPL (Task Parallel Library), a subset of the .NET BCL (Base Class Library) and entirely handled as libraries, which any language can use/interact with even without async/await language support. The async/await language support in C# is basically a Monad transformer, building a generator-like asynchronous state machine. (The output of an async/await function in C# is rather similar in concept/implementation to the output of a generator function using yield syntax.) This is also why F# has never had a tough time with async/await because it has even more generic Monad transformer support ("computation expressions"). Any "alt-lang" could make use of the TPL whether or not they could transform their own similar syntax, and there's nothing stopping them from building a similar syntax. As far as I saw that wasn't a killer of languages.
- orthoxerox 3y ago
  It wasn't a break at the CLR level, but it was a break at the BCL level. To consume the new async methods your language had to come up with a mechanism that was broadly similar to how C# worked or miss out on the vast majority of libraries and the BCL itself.
  - WorldMaker 3y ago
    If a language didn't do anything at all like C# it dealt with a lot of task.ContinueWith(value => {}) callbacks (Action<T>), no different to JS promise.then(value => {}) chaining (truly, no different at all because Task/Promise are basically twins). At worst case you had callback "waterfalls" to deal with, but that was hardly "breaking" and shouldn't have "killed" languages. async/await is much nicer than callbacks/callback waterfalls, but that doesn't mean you can't write callbacks/callback waterfalls (a lot of JS projects certainly did; many still do even despite most browsers supporting async/await today).
    - orthoxerox 3y ago
      The language would also need to have some support for anonymous delegates and closures, or its callback waterfalls would have to be broken up into multiple methods that would have to manage the call state themselves. CLS really expected most languages to look a lot of like early C#, that is, Java with some Delphi/VB features grafted on.

chubot 3y ago

> But CLR stands for Common Language Runtime and had three official languages shortly after release (VB.NET, C# and J#, offhand). CLR is not really common -- the "tells" are VB.NET and PowerShell. VB6 was a very popular and useful language, and VB.NET broke everything in that ecosystem, turning it into a variant of C# with different syntax. Does that sound like a multi-language VM? If so, why not compile VB6 to it? PowerShell is likewise best described as C# with a horrible shell-like syntax. It's not really a shell in the original sense, because it doesn't talk to the kernel directly -- it runs on a VM, which mediates all access to the kernel. fork() is a syscall that shells rely on critically, which is problematic for almost all VMs. Some notes on "interior" (VM-based) vs "exterior" (OS kernel-based) shells here: https://www.oilshell.org/blog/2023/06/ysh-design.html https://www.oilshell.org/blog/2023/06/ysh-design.html

mmcdermott 3y ago
It was intended to be common whether or not it succeeded. Those examples point to a differing design philosophy at Microsoft rather than some inability to write a language on the CLR. The design philosophy was clearly to do Java-ish typing across the board, supplanting VB6's loose typing and bash's text based mindset. I don't really like the approach. I think shell scripting succeeds because it allows ad-hoc programming and I don't think Java-ish weak but static typing is some perfect ideal to be used everywhere, but you could certainly implement a more loosely typed language on the CLR.