3 ms·

I think it's safe to say that was the case before .NET 4 introduced the dynamic language runtime. Afterwards, I'm not so sure - it seems like the story there wa

I think it's safe to say that was the case before .NET 4 introduced the dynamic language runtime. Afterwards, I'm not so sure - it seems like the story there was that the .NET team put a whole lot of work into building support for IronRuby and IronPython, but the languages themselves failed to take off for other reasons. Lack of community need/interest, for one. To me, the more interesting test is, could you do a useful port of a language like C or Pascal or ML to the JVM or the CLR, while having it remain the same language. My instinct is that it's equally unworkable for both platforms. Requiring erasure vs reification is a small difference compared to the major demand that both platforms make, which is that any languages targeting them need to be at least partially object-oriented.

seanmcdirmid 8y ago
The DLR was only going to ever work out for dynamic languages, and even then I think it was pretty limited to class-based ones like Python and Ruby. Unfortunately, the DLR seems to be pretty much deprecated at this point. Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP).
- benaadams 8y ago
  > Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP). That's more to do with UWP being a AOT platform than it being deprecated; it should still work fine with .NET Core?
  - seanmcdirmid 8y ago
    I have no idea. I’ve mostly been interested in UI work anyways, and not being able to move to the new UI stack really sucked for me. Now it’s all just a bunch of bad choices.
  - pjmlp 8y ago
    They are rebooting the .NET AOT story after the 3.0 release. It was discussed during this week Connect(), on the ".NET today and tomorrow" Q&A session. https://channel9.msdn.com/Events/Connect/Microsoft-Connect--2018/T150 https://channel9.msdn.com/Events/Connect/Microsoft-Connect--... The video is not yet available though.
int_19h 8y ago
The DLR goes beyond running dynamically typed languages on CLR, though. For example, there's the Python.NET library, which lets you embed regular Python (not IronPython!) into a .NET app - and it still uses "dynamic" etc.
int_19h 8y ago
> To me, the more interesting test is, could you do a useful port of a language like C or Pascal or ML to the JVM or the CLR, while having it remain the same language. Yes, you could. In fact, for C, this is experimentally proven - if you compile your C or C++ code with MSVC using /clr:pure, you'll get pure IL as output. This is by design - CLR is powerful and flexible enough to map any C construct, including raw pointers, unions etc, precisely because compiling C++ to it was always a requirement. Of course, the result isn't verifiably safe - but unlike JVM, CLR doesn't require verifiable code to be able to run it! Consequently, if you can compile something to C, you can compile it to IL, and run it on CLR. In fact, there are even things that you can't compile to C that you can do in IL - for example, it has a tailcall opcode, which performs guaranteed tailcalls. So, yes, you would be able to compile Pascal or ML to it. The reason why languages still adapt to CLR is because they don't just want to use it as a VM - they want to interop with other code that runs on it. In theory, it would be possible for two languages both hosted on CLR to use the equivalent of the C ABI to interoperate, but in practice nobody does that, and of course the .NET standard library is nothing like that. So if your language wants to be able to use .NET libraries, it has to support the .NET object model - and it is at that point that you get language dialects like C++/CLI.

seanmcdirmid 8y ago

The DLR was only going to ever work out for dynamic languages, and even then I think it was pretty limited to class-based ones like Python and Ruby. Unfortunately, the DLR seems to be pretty much deprecated at this point. Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP).

benaadams 8y ago
> Its a shame, I was able to do great things with the run-time generation API (which now defaults to an interpreter in UWP). That's more to do with UWP being a AOT platform than it being deprecated; it should still work fine with .NET Core?
- seanmcdirmid 8y ago
  I have no idea. I’ve mostly been interested in UI work anyways, and not being able to move to the new UI stack really sucked for me. Now it’s all just a bunch of bad choices.
- pjmlp 8y ago
  They are rebooting the .NET AOT story after the 3.0 release. It was discussed during this week Connect(), on the ".NET today and tomorrow" Q&A session. https://channel9.msdn.com/Events/Connect/Microsoft-Connect--2018/T150 https://channel9.msdn.com/Events/Connect/Microsoft-Connect--... The video is not yet available though.

int_19h 8y ago

The DLR goes beyond running dynamically typed languages on CLR, though. For example, there's the Python.NET library, which lets you embed regular Python (not IronPython!) into a .NET app - and it still uses "dynamic" etc.

int_19h 8y ago

> To me, the more interesting test is, could you do a useful port of a language like C or Pascal or ML to the JVM or the CLR, while having it remain the same language. Yes, you could. In fact, for C, this is experimentally proven - if you compile your C or C++ code with MSVC using /clr:pure, you'll get pure IL as output. This is by design - CLR is powerful and flexible enough to map any C construct, including raw pointers, unions etc, precisely because compiling C++ to it was always a requirement. Of course, the result isn't verifiably safe - but unlike JVM, CLR doesn't require verifiable code to be able to run it! Consequently, if you can compile something to C, you can compile it to IL, and run it on CLR. In fact, there are even things that you can't compile to C that you can do in IL - for example, it has a tailcall opcode, which performs guaranteed tailcalls. So, yes, you would be able to compile Pascal or ML to it. The reason why languages still adapt to CLR is because they don't just want to use it as a VM - they want to interop with other code that runs on it. In theory, it would be possible for two languages both hosted on CLR to use the equivalent of the C ABI to interoperate, but in practice nobody does that, and of course the .NET standard library is nothing like that. So if your language wants to be able to use .NET libraries, it has to support the .NET object model - and it is at that point that you get language dialects like C++/CLI.