10 ms·

Just to point out that, as much as the CLR was specced as cross-language, it's damn hard to run Java on it, Python and Ruby are abandoned, no-one's even tried H

by moomin 12y ago

Just to point out that, as much as the CLR was specced as cross-language, it's damn hard to run Java on it, Python and Ruby are abandoned, no-one's even tried Haskell.

Solarsail 12y ago
Isn't this a general problem of cross-language VMs? Different languages need different object models, and different data representations. [0] At least according to one Parrot developer, the Parrot object model was one of the biggest pain points for porting JS/Ruby/Python to Parrot... Where that object model was meant to be universal, and work for any language. [1] That said, IronPython does still semi-exist [2], and I'm not sure how well JRuby handles interoperability with Java or Jython... [0] One former dev on one of the Iron* languages posted on reddit about how the CLR failed on its cross language ambitions. I can't find the post, but they gradually found it was mostly C# centric anyways, and ports of other languages were mostly incompatible and second-class [1] http://whiteknight.github.io/2015/01/15/parrottheend.html http://whiteknight.github.io/2015/01/15/parrottheend.html [2] http://ironpython.net/announcements/ http://ironpython.net/announcements/ for what it's worth...
- larsberg 12y ago
  It's a hard problem, which the COMPlus team knew when they started out. During the early pre-release period, there was a then-NDA-only project, Project 7, which gave grants to people trying to port both commercial languages like perl and academic languages like scheme. I was at Northwestern, where we got a Project 7 grant to work on a scheme implementation (under Ian Horswill, done by Pinku Surana in my group) and scheme language service (done by me). We provided a lot of feedback, but it's tough for a group of a couple of students (or in the case of Perl, one commercial dev) to keep up with the then massive-breaking-changes drops we'd get from DevDiv every 3 months or so and provide feedback when it was on stuff that was, to the developers, around 6 months old. Often, by the time feedback landed, it was "too late" to incorporate because of product cycles and got postponed. Or the stuff we'd request was a dupe of "add tail call instruction" which had been postponed long before any of us got started in Project 7. I say this as somebody who then graduated and then went to work in DevDiv for the next 7 years, where I was treated very well, so I certainly have no axes to grind on that front :-)
  - moomin 12y ago
    The strange thing is they seemed to have had a bit of cognitive dissonance from the outset. They wanted to support Java and JavaScript, but the semantics of their Java and JavaScript basically made them different syntaxes for C#. On the other hand, they've put a lot of effort into support tail calls. On the third, it's only really used by F#, which is .NET specific. :(
- zeendo 12y ago
  JRuby interops fine with Java. Any specific thing you might be curious about? One example is Rack applications are hosted by Java web containers Just Fine via a server -> Rack mapping. We use this in production for both a Sinatra app and a Rails app.
  - Solarsail 12y ago
    Interesting! Does that (partially) obsolete this answer [0]? Do Ruby programs see Java objects as a separate kind of Object, or is it seamless? Is there a translation layer anywhere? Does JRuby-Rack have to use wrappers for Java functions? [0] http://stackoverflow.com/questions/2752979/using-jruby-jython-for-ruby-python-interoperability http://stackoverflow.com/questions/2752979/using-jruby-jytho...
CmonDev 12y ago
Blame communities and past lack of OSS spirit. E.g. Clojure CLR is doing well, Scala kind of missed the opportunity to win C# devs with their CLR version by abandoning it. CLR is the enabler, not implementator.
- k__ 12y ago
  > Blame communities and past lack of OSS spirit The communities aren't to blame, but Microsoft. Like you said, the past lack of OSS spirit. But maybe things are changing now :)
- moomin 12y ago
  The thing is, ClojureCLR is a demonstration of of exactly what's wrong with the CLR: it isn't Clojure. Instead it's a language with similar decisions and similar syntax but slightly different semantics.
  - joshuacc 12y ago
    Would you say that is true of ClojureScript as well? If not, what sort of differences are there in ClojureCLR?
    - nickik 12y ago
      The problem with ClojureCLR is not technical, its just that most people dont care about it. There are some things moving there but not anywhere close to Clojure or ClojureScript. Clojure has never, ever been about equality between diffrent versions, the were always meant to be simular but diffrent when the platform is diffrent.
      - moomin 12y ago
        I think you're getting mixed up. ClojureCLR demonstrates that CoreCLR doesn't deliver on its intended functionality, not that Clojure's approach is wrong. Indeed, Clojure's approach is dead on: don't even try to make platforms compatible. With that said, I'd like a better lib story between Clj and Cljs.
ceronman 12y ago
Not sure why you say Python on the CLR is abandoned. The last release of IronPython was on December 6, 2014.
MichaelGG 12y ago
Yeah it was a great dream, and to be sure, they do support a fair amount more than C#. The availability of pointers, for instance. It's slightly ironic that the inferior JVM is where all the languages run. But that might just be MS being pigheaded with the license to the CLR up until now. (They had an open source version called Rotor that ran on FreeBSD and Mac OS X, but a very limited license - this was around 2003 IIRC.) But it's clear that MS does not really care about other languages. The APIs they ship are often C# only, taking advantage of quirks in the C# compiler, even. This document would have been better off written several years before, when reality hadn't set it. And also vice versa. The C# compiler has always needed "duck" typing, but instead of exposing it in any principled way, they simply hack it into the compiler on an as-needed basis. The runtime hasn't been updated in about a decade, to boot. So, apart from the F# folks valiantly getting generics pushed in for v2, everything's been essentially frozen for over a decade. There may have been some kerfuffle around boxing of null nullable types, but nothing serious. Serious, deep, flaws, line reference types always being allowed to be null, just go unquestioned as part of the C way of thinking. I feel like this was the same as IE. MS saw a huge threat in Java, and responded excellently. Then, after matching it, they got complacent. Part of the issue may have been the Longhorn fiasco. Without a strong runtime (apart from whatever managerial issues), they couldn't ship an OS, and I think the managed code people lost too much political capital to really drive a continuing difference. Although, even before that, teams inside MS (like Office), were totally against taking a dependency on .Net. I wonder if a light, optional, ownership system would have provided the performance necessary to have pulled it off. Then you could do something like play with an array without making heap allocations galore. The GC is great, but even short lived, gen0 garbage has considerable costs. (In practice, I could measure a single allocation's impact on a per packet (network sniffer app) basis.) The CLR advancing at this point seems highly unlikely. C# and it's nearly isomorphic verbose flavor, VB.NET, have decided that advancement is a compiler thing only. Something like type classes? Simple annotations for ownership to allow some use of the stack? I will always dream.
- Rapzid 12y ago
  * DLR * LINQ+Generics(It's my understand much of the generics work was done for LINQ, not F#) * RyuJIT * New GC Modes * Re-Jit * MPGO * Thread pools and TPL The CLR is under constant development. I think, if anything, now that you can upgrade your CLR version on a per-project, per-build basis there should be an acceleration of released improvements.
kvb 12y ago
Can you elaborate on the issues with running Java on the CLR? I always thought IKVM had a great reputation.

by moomin 12y ago

Just to point out that, as much as the CLR was specced as cross-language, it's damn hard to run Java on it, Python and Ruby are abandoned, no-one's even tried Haskell.

Solarsail 12y ago

Isn't this a general problem of cross-language VMs? Different languages need different object models, and different data representations. [0] At least according to one Parrot developer, the Parrot object model was one of the biggest pain points for porting JS/Ruby/Python to Parrot... Where that object model was meant to be universal, and work for any language. [1] That said, IronPython does still semi-exist [2], and I'm not sure how well JRuby handles interoperability with Java or Jython... [0] One former dev on one of the Iron* languages posted on reddit about how the CLR failed on its cross language ambitions. I can't find the post, but they gradually found it was mostly C# centric anyways, and ports of other languages were mostly incompatible and second-class [1] http://whiteknight.github.io/2015/01/15/parrottheend.html http://whiteknight.github.io/2015/01/15/parrottheend.html [2] http://ironpython.net/announcements/ http://ironpython.net/announcements/ for what it's worth...

larsberg 12y ago
It's a hard problem, which the COMPlus team knew when they started out. During the early pre-release period, there was a then-NDA-only project, Project 7, which gave grants to people trying to port both commercial languages like perl and academic languages like scheme. I was at Northwestern, where we got a Project 7 grant to work on a scheme implementation (under Ian Horswill, done by Pinku Surana in my group) and scheme language service (done by me). We provided a lot of feedback, but it's tough for a group of a couple of students (or in the case of Perl, one commercial dev) to keep up with the then massive-breaking-changes drops we'd get from DevDiv every 3 months or so and provide feedback when it was on stuff that was, to the developers, around 6 months old. Often, by the time feedback landed, it was "too late" to incorporate because of product cycles and got postponed. Or the stuff we'd request was a dupe of "add tail call instruction" which had been postponed long before any of us got started in Project 7. I say this as somebody who then graduated and then went to work in DevDiv for the next 7 years, where I was treated very well, so I certainly have no axes to grind on that front :-)
- moomin 12y ago
  The strange thing is they seemed to have had a bit of cognitive dissonance from the outset. They wanted to support Java and JavaScript, but the semantics of their Java and JavaScript basically made them different syntaxes for C#. On the other hand, they've put a lot of effort into support tail calls. On the third, it's only really used by F#, which is .NET specific. :(
zeendo 12y ago
JRuby interops fine with Java. Any specific thing you might be curious about? One example is Rack applications are hosted by Java web containers Just Fine via a server -> Rack mapping. We use this in production for both a Sinatra app and a Rails app.
- Solarsail 12y ago
  Interesting! Does that (partially) obsolete this answer [0]? Do Ruby programs see Java objects as a separate kind of Object, or is it seamless? Is there a translation layer anywhere? Does JRuby-Rack have to use wrappers for Java functions? [0] http://stackoverflow.com/questions/2752979/using-jruby-jython-for-ruby-python-interoperability http://stackoverflow.com/questions/2752979/using-jruby-jytho...

CmonDev 12y ago

Blame communities and past lack of OSS spirit. E.g. Clojure CLR is doing well, Scala kind of missed the opportunity to win C# devs with their CLR version by abandoning it. CLR is the enabler, not implementator.

k__ 12y ago
> Blame communities and past lack of OSS spirit The communities aren't to blame, but Microsoft. Like you said, the past lack of OSS spirit. But maybe things are changing now :)
moomin 12y ago
The thing is, ClojureCLR is a demonstration of of exactly what's wrong with the CLR: it isn't Clojure. Instead it's a language with similar decisions and similar syntax but slightly different semantics.
- joshuacc 12y ago
  Would you say that is true of ClojureScript as well? If not, what sort of differences are there in ClojureCLR?
  - nickik 12y ago
    The problem with ClojureCLR is not technical, its just that most people dont care about it. There are some things moving there but not anywhere close to Clojure or ClojureScript. Clojure has never, ever been about equality between diffrent versions, the were always meant to be simular but diffrent when the platform is diffrent.
    - moomin 12y ago
      I think you're getting mixed up. ClojureCLR demonstrates that CoreCLR doesn't deliver on its intended functionality, not that Clojure's approach is wrong. Indeed, Clojure's approach is dead on: don't even try to make platforms compatible. With that said, I'd like a better lib story between Clj and Cljs.

ceronman 12y ago

Not sure why you say Python on the CLR is abandoned. The last release of IronPython was on December 6, 2014.

MichaelGG 12y ago

Yeah it was a great dream, and to be sure, they do support a fair amount more than C#. The availability of pointers, for instance. It's slightly ironic that the inferior JVM is where all the languages run. But that might just be MS being pigheaded with the license to the CLR up until now. (They had an open source version called Rotor that ran on FreeBSD and Mac OS X, but a very limited license - this was around 2003 IIRC.) But it's clear that MS does not really care about other languages. The APIs they ship are often C# only, taking advantage of quirks in the C# compiler, even. This document would have been better off written several years before, when reality hadn't set it. And also vice versa. The C# compiler has always needed "duck" typing, but instead of exposing it in any principled way, they simply hack it into the compiler on an as-needed basis. The runtime hasn't been updated in about a decade, to boot. So, apart from the F# folks valiantly getting generics pushed in for v2, everything's been essentially frozen for over a decade. There may have been some kerfuffle around boxing of null nullable types, but nothing serious. Serious, deep, flaws, line reference types always being allowed to be null, just go unquestioned as part of the C way of thinking. I feel like this was the same as IE. MS saw a huge threat in Java, and responded excellently. Then, after matching it, they got complacent. Part of the issue may have been the Longhorn fiasco. Without a strong runtime (apart from whatever managerial issues), they couldn't ship an OS, and I think the managed code people lost too much political capital to really drive a continuing difference. Although, even before that, teams inside MS (like Office), were totally against taking a dependency on .Net. I wonder if a light, optional, ownership system would have provided the performance necessary to have pulled it off. Then you could do something like play with an array without making heap allocations galore. The GC is great, but even short lived, gen0 garbage has considerable costs. (In practice, I could measure a single allocation's impact on a per packet (network sniffer app) basis.) The CLR advancing at this point seems highly unlikely. C# and it's nearly isomorphic verbose flavor, VB.NET, have decided that advancement is a compiler thing only. Something like type classes? Simple annotations for ownership to allow some use of the stack? I will always dream.

Rapzid 12y ago
* DLR * LINQ+Generics(It's my understand much of the generics work was done for LINQ, not F#) * RyuJIT * New GC Modes * Re-Jit * MPGO * Thread pools and TPL The CLR is under constant development. I think, if anything, now that you can upgrade your CLR version on a per-project, per-build basis there should be an acceleration of released improvements.

kvb 12y ago

Can you elaborate on the issues with running Java on the CLR? I always thought IKVM had a great reputation.