4 ms·

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 imp

• 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.
  • gilest 17y ago
    There are actually two third-party plugins for Excel that let you use IronPython for scripting to some degree: DiscoveryScript at http://www.xefion.com/getting_started_diss.html http://www.xefion.com/getting_started_diss.html and PyXLL at http://www.pyxll.com/ http://www.pyxll.com/ -- I don't use either, though, so I can't comment on how good they are. (BTW thanks for the kind words about Resolver One -- that's my day job :-)
    • clofresh 17y ago
      Sweet, thanks! I'll be sure to try them out. Np re: Resolver One. How is it working there? When are you guys gonna kill Microsoft already?? ;p
      • gilest 17y ago
        Oh, it's tough -- crushing Microsoft beneath your feet is hard work ;-)
    • echion 17y ago
      I use PyXLL and it works great.