3 ms·

Counter examples .. 1) On top of the JVM we've got Scala, Clojure, JRuby, Jython, Groovy, Fantom, very successful, very active, with big communities. 2) On to

Counter examples .. 1) On top of the JVM we've got Scala, Clojure, JRuby, Jython, Groovy, Fantom, very successful, very active, with big communities. 2) On top of the CLR, we've got IronRuby dead, IronPython dead, Clojure.NET almost dead, Scala.NET dead. VB is C# with a different syntax. The only partial success story is F#, executed by Microsoft and I say partial because its impact is less than Clojure, Scala or JRuby, in spite of Microsoft promoting it. So you see, something is wrong with your assessment and you've been listening too much to marketing pamphlets.

rayiner 13y ago
That's not a technical argument. Nobody wants to build on the CLR because its closed source and Microsoft tightly controls it. But the person I replies to claimed it was full of design mistakes, which is different.
- bad_user 13y ago
  True, I never read the parent comment, sorry. The CLR is definitely not full of design mistakes, it's actually quite awesome. But in terms of technical arguments, the JVM is better for dynamic languages, as it can do all sorts of optimizations at runtime that the CLR is not capable of. It's not that Microsoft couldn't improve it, but C# would have nothing to gain as it was designed to not need runtime optimizations (e.g. on the JVM, AOT compiler optimizations can actually get in the way, whereas the C# engineers focus on optimizing the compiler). And the new InvokeDynamic from JDK 7 is amazing. Starting with Java 8, it will even have benefits for static languages, like Scala. Scala for example has the notion of "lazy val", which are final references initialized on first access. In the current implementation, lazy vals have a performance penalty on access, as the generated code implies synchronization on the underlying reference, however Java 8 will make it possible to declare the generated values as being effectively constants. The JVM also has a more capable garbage collector(s) for more wasteful languages. It makes a world of difference for languages like Scala or Clojure (e.g. functional languages use a lot of persistent immutable data-structures which generate a lot more junk than their imperative counterparts). On the community side, for the JVM there are more capable libraries for generating bytecode. Also the ECMA standard has been kind of incomplete. For example Mono had to use for a long time their own format for the debugging symbols, while slowly reverse-engineering Microsoft's format. The debugging symbols on the JVM are documented and directly a part of the generated bytecode. Sun made many good choices here too. A JAR is just a zip containing .class files and other resources. It's definitely easier to generate JARs than it is to generate DLLs. I think language developers have a much easier time generating code for the JVM. There is one feature of the CLR that stands in the way of dynamic languages and that is the reified generics support. The JVM has fewer restrictions, although in truth both suck for languages that are not Java or C#.
tedunangst 13y ago
IronPython is dead?

rayiner 13y ago

That's not a technical argument. Nobody wants to build on the CLR because its closed source and Microsoft tightly controls it. But the person I replies to claimed it was full of design mistakes, which is different.

bad_user 13y ago
True, I never read the parent comment, sorry. The CLR is definitely not full of design mistakes, it's actually quite awesome. But in terms of technical arguments, the JVM is better for dynamic languages, as it can do all sorts of optimizations at runtime that the CLR is not capable of. It's not that Microsoft couldn't improve it, but C# would have nothing to gain as it was designed to not need runtime optimizations (e.g. on the JVM, AOT compiler optimizations can actually get in the way, whereas the C# engineers focus on optimizing the compiler). And the new InvokeDynamic from JDK 7 is amazing. Starting with Java 8, it will even have benefits for static languages, like Scala. Scala for example has the notion of "lazy val", which are final references initialized on first access. In the current implementation, lazy vals have a performance penalty on access, as the generated code implies synchronization on the underlying reference, however Java 8 will make it possible to declare the generated values as being effectively constants. The JVM also has a more capable garbage collector(s) for more wasteful languages. It makes a world of difference for languages like Scala or Clojure (e.g. functional languages use a lot of persistent immutable data-structures which generate a lot more junk than their imperative counterparts). On the community side, for the JVM there are more capable libraries for generating bytecode. Also the ECMA standard has been kind of incomplete. For example Mono had to use for a long time their own format for the debugging symbols, while slowly reverse-engineering Microsoft's format. The debugging symbols on the JVM are documented and directly a part of the generated bytecode. Sun made many good choices here too. A JAR is just a zip containing .class files and other resources. It's definitely easier to generate JARs than it is to generate DLLs. I think language developers have a much easier time generating code for the JVM. There is one feature of the CLR that stands in the way of dynamic languages and that is the reified generics support. The JVM has fewer restrictions, although in truth both suck for languages that are not Java or C#.

tedunangst 13y ago

IronPython is dead?