3 ms·

Not sure if the .NET dynamic languages (IronPython, IronRuby, etc) came before the JVM dynamic languages (Jython, JRuby, etc), but it also seems like Microsoft

Not sure if the .NET dynamic languages (IronPython, IronRuby, etc) came before the JVM dynamic languages (Jython, JRuby, etc), but it also seems like Microsoft let the .NET languages languish and missed out on a opportunity to bring a lot of the dynamic language programmers into the .NET fold. Meanwhile the the JVM has experienced a rebirth with the vibrant JVM language communities.

rdtsc 17y ago
> missed out on a opportunity to bring a lot of the dynamic language programmers into the .NET fold. I think one of the reasons is that they are well ... Microsoft. It is irrational, it doesn't make sense, but that's the vibe I get. Their languages and ideas are not bad, I think it is the association with their company that is somehow hurting them. For example, F# is a very nice language, but I think the fact that it runs on .NET is putting off a lot of people. It seems to me if F# wasn't related in any way to Microsoft, it would have fared a lot better.
- prodigal_erik 17y ago
  Blub paradox. There are a limited number of programmers who wouldn't automatically dismiss F# as too weird to bother learning, and the ones who don't need .NET support are already using OCaml (or Haskell or whatever).
halo 17y ago
I'm not sure what makes you think Microsoft have let .NET languish. The .NET runtime and languages have been updated regularly with significant changes and improvements, and Microsoft themselves support C#, VB.NET and F# as "first-class" languages, as well as developing IronPython and IronRuby and working on the Dynamic Language Runtime project to ease dynamic language implementation. All of these equal or better Sun's support of Java. There are also quite a few non-Microsoft languages based on .NET including IronScheme and Boo. .NET's CLR also supports tail-call optimisation, something the JVM doesn't.
- bad_user 17y ago
  The CLR may support tail-call optimization, but that's not much. You can have support for TCO in a JVM language, it's just that interoperability with Java suffers. When comparing the CLR to the JVM, I'm only jealous of one feature of the CLR ... stack-allocated objects. On the other hand, saying that .NET's support for multiple languages is "equal or better" then that of the JVM is just flat wrong. The CLR doesn't optimize call-sites where the called method is virtual. This is alleviated somewhat by the semantics of C# (all methods are non-virtual by default), but for dynamic languages it's a disaster. The JVM on the other hand does this ever since Java 1.3 (when hotspot was added as an option). And the DLR is a cool framework for language designers, but it's one layer above the CLR, and it's just code extracted from the IronPython implementation. And related to speed, if you compare Jython with IronPython, Jython does a lot better right now, although it's not the most active language-implementation on the JVM. The upcoming InvokeDynamic for the JVM will really kick ass for dynamic invocations ... the JVM will allow one to make calls without knowing the type of the object used in single dispatch ... and those call-sites will be optimized (like method-inlining) just as with a normal "invoke_interface". And then there's the little things that make your life easier on the JVM ... for example it's easier to generate .class files, or .jar files ... along with debugging symbols. And the JVM is truly multi-platform. You mentioned tail-calls ... well, the tail-calls in Mono have always been broken and unusable and there's no fix on the horizon. Also speaking of Mono, the GC is not generational and does not defragment the heap. IMHO, it's a low quality implementation that's only optimized for C#.
  - halo 17y ago
    Interesting, I'll bow to your greater experience that Java bytecote is better as a target than CIL.. That said, I think that my core point still stands, even if the CLR isn't yet quite as good as the JVM: Microsoft are hardly letting .NET languish.
- clofresh 17y ago
  I didn't mean .NET in general, I just meant .NET support for ports of existing open source languages like IronPython and IronRuby. Admittedly, I don't really dabble with the .NET ecosystem much, but when I had to use SQL Server Reporting Services for a work project and we had to create a custom data source, we had to write the component in C#, it didn't support other .NET languages (I think it also supported VB.NET, but yeah, no thanks). That would have been a logical place to allow for extending their code with a language that I was more comfortable with. There's also the ignored opportunity to provide better scripting in their Office offerings. While Resolver One is a really cool idea (spreadsheet built and scripted in IronPython), what I would REALLY love is to be able to call IronPython from Excel, but it's probably not gonna happen.

rdtsc 17y ago

> missed out on a opportunity to bring a lot of the dynamic language programmers into the .NET fold. I think one of the reasons is that they are well ... Microsoft. It is irrational, it doesn't make sense, but that's the vibe I get. Their languages and ideas are not bad, I think it is the association with their company that is somehow hurting them. For example, F# is a very nice language, but I think the fact that it runs on .NET is putting off a lot of people. It seems to me if F# wasn't related in any way to Microsoft, it would have fared a lot better.

prodigal_erik 17y ago
Blub paradox. There are a limited number of programmers who wouldn't automatically dismiss F# as too weird to bother learning, and the ones who don't need .NET support are already using OCaml (or Haskell or whatever).

halo 17y ago

I'm not sure what makes you think Microsoft have let .NET languish. The .NET runtime and languages have been updated regularly with significant changes and improvements, and Microsoft themselves support C#, VB.NET and F# as "first-class" languages, as well as developing IronPython and IronRuby and working on the Dynamic Language Runtime project to ease dynamic language implementation. All of these equal or better Sun's support of Java. There are also quite a few non-Microsoft languages based on .NET including IronScheme and Boo. .NET's CLR also supports tail-call optimisation, something the JVM doesn't.

bad_user 17y ago
The CLR may support tail-call optimization, but that's not much. You can have support for TCO in a JVM language, it's just that interoperability with Java suffers. When comparing the CLR to the JVM, I'm only jealous of one feature of the CLR ... stack-allocated objects. On the other hand, saying that .NET's support for multiple languages is "equal or better" then that of the JVM is just flat wrong. The CLR doesn't optimize call-sites where the called method is virtual. This is alleviated somewhat by the semantics of C# (all methods are non-virtual by default), but for dynamic languages it's a disaster. The JVM on the other hand does this ever since Java 1.3 (when hotspot was added as an option). And the DLR is a cool framework for language designers, but it's one layer above the CLR, and it's just code extracted from the IronPython implementation. And related to speed, if you compare Jython with IronPython, Jython does a lot better right now, although it's not the most active language-implementation on the JVM. The upcoming InvokeDynamic for the JVM will really kick ass for dynamic invocations ... the JVM will allow one to make calls without knowing the type of the object used in single dispatch ... and those call-sites will be optimized (like method-inlining) just as with a normal "invoke_interface". And then there's the little things that make your life easier on the JVM ... for example it's easier to generate .class files, or .jar files ... along with debugging symbols. And the JVM is truly multi-platform. You mentioned tail-calls ... well, the tail-calls in Mono have always been broken and unusable and there's no fix on the horizon. Also speaking of Mono, the GC is not generational and does not defragment the heap. IMHO, it's a low quality implementation that's only optimized for C#.
- halo 17y ago
  Interesting, I'll bow to your greater experience that Java bytecote is better as a target than CIL.. That said, I think that my core point still stands, even if the CLR isn't yet quite as good as the JVM: Microsoft are hardly letting .NET languish.
clofresh 17y ago
I didn't mean .NET in general, I just meant .NET support for ports of existing open source languages like IronPython and IronRuby. Admittedly, I don't really dabble with the .NET ecosystem much, but when I had to use SQL Server Reporting Services for a work project and we had to create a custom data source, we had to write the component in C#, it didn't support other .NET languages (I think it also supported VB.NET, but yeah, no thanks). That would have been a logical place to allow for extending their code with a language that I was more comfortable with. There's also the ignored opportunity to provide better scripting in their Office offerings. While Resolver One is a really cool idea (spreadsheet built and scripted in IronPython), what I would REALLY love is to be able to call IronPython from Excel, but it's probably not gonna happen.