4 ms·

[the following is apocryphal, citations needed] The difference in how .net and java implement generics is a big factor; Java implements them with erasure (basic

by brehaut 16y ago

[the following is apocryphal, citations needed] The difference in how .net and java implement generics is a big factor; Java implements them with erasure (basicly existing only at compile time), CLR tracks them on the runtime. This makes it very hard for languages on the CLR to coexist with other languages if they do not provide that parametric typing information. This is for instance the big thing holding up the CLR port of clojure itself.* Re:static languages on the JVM, in addition to the poster boy scala, see http://mth.github.com/yeti/ http://mth.github.com/yeti/ an ML style language. [ * i have no idea how the DLR and .net 4 stuff changes this situation ]

bad_user 16y ago
> This is for instance the big thing holding up the CLR port of clojure itself. I have no idea about the hurdles Clojure on top of .NET is facing, but if it isn't ported by now it's more likely because Rich Hickey and the other core contributors don't have a strong interest for it. The other problem would be that compatibility between the JVM/CLR versions would be affected. > This makes it very hard for languages on the CLR to coexist with other languages If you'll look closely, you can say the same thing about languages on top of the JVM ;)
- brehaut 16y ago
  You seem to have a much better handle on things than i so i'll take your word for it. > I have no idea about the hurdles Clojure on top of .NET is facing, but if it isn't ported by now it's more likely because Rich Hickey and the other core contributors don't have a strong interest for it. found a quote that i was thinking of when wrote that first comment rhickey: cemerick: depends cemerick: erasure is the best thing ever cemerick: yeah; I caught a glimpse of what D. Miller is having to deal with with ClojureCLR, and felt bad for him. rhickey: cemerick: yes, people don't realize the huge tradeoff involved in the CLR approach. It greatly complicates life for everyone, and is a poor fit for dynamic langs -- http://clojure-log.n01se.net/date/2010-06-01.html#i30 http://clojure-log.n01se.net/date/2010-06-01.html#i30
  - bad_user 16y ago
    Interesting ... can you find technical details on that? ... I guess the more static typing you have to deal with when generating bytecode, the harder it is for dynamic language writers. Still, generics are used to great effect in the DLR for the call-sites inline caches ... like when you have a "doSomething(x, 2)" ... you know that "2" is an integer constant, and the generated call-site method that does the inline caching (to avoid hash-lookups) is using an "int" as the second parameter ... they can do that because method references are getting specialized so you can avoid boxing/unboxing for obvious cases, like passing integer/double constants. [EDIT] The MethodHandler from OpenJDK's invokedynamic proposal is a light-weight method reference, resembling System.Reflection.Emit.DynamicMethod from dotNet. MethodHandler will be used for call-sites and I think MethodHandler also gets reified. The thing I don't like about the JVM are the inconsistencies ... you've got primitive types, but you can't define your own. Arrays are reified (and now MethodHandlers too) ... but you have no way to have your own reified generic data-structures. Still ... in the long-run I think the JVM is a better platform than .NET ... if only Oracle would not stagnate it (or maybe now that it's open-source, some fork might be in order ... but I don't think it's doable unless it's a big company with lots of resources ... maybe Google, but I'm not holding my breath).
    - brehaut 16y ago
      > Interesting ... can you find technical details on that? ... Unfortunately not; mostly comments in passing on IRC or in videos. That DLR (and invokedynamic) stuff sounds really clever, if you've got any related links i'd be interested in reading more.

by brehaut 16y ago

bad_user 16y ago

> This is for instance the big thing holding up the CLR port of clojure itself. I have no idea about the hurdles Clojure on top of .NET is facing, but if it isn't ported by now it's more likely because Rich Hickey and the other core contributors don't have a strong interest for it. The other problem would be that compatibility between the JVM/CLR versions would be affected. > This makes it very hard for languages on the CLR to coexist with other languages If you'll look closely, you can say the same thing about languages on top of the JVM ;)

brehaut 16y ago
You seem to have a much better handle on things than i so i'll take your word for it. > I have no idea about the hurdles Clojure on top of .NET is facing, but if it isn't ported by now it's more likely because Rich Hickey and the other core contributors don't have a strong interest for it. found a quote that i was thinking of when wrote that first comment rhickey: cemerick: depends cemerick: erasure is the best thing ever cemerick: yeah; I caught a glimpse of what D. Miller is having to deal with with ClojureCLR, and felt bad for him. rhickey: cemerick: yes, people don't realize the huge tradeoff involved in the CLR approach. It greatly complicates life for everyone, and is a poor fit for dynamic langs -- http://clojure-log.n01se.net/date/2010-06-01.html#i30 http://clojure-log.n01se.net/date/2010-06-01.html#i30
- bad_user 16y ago
  Interesting ... can you find technical details on that? ... I guess the more static typing you have to deal with when generating bytecode, the harder it is for dynamic language writers. Still, generics are used to great effect in the DLR for the call-sites inline caches ... like when you have a "doSomething(x, 2)" ... you know that "2" is an integer constant, and the generated call-site method that does the inline caching (to avoid hash-lookups) is using an "int" as the second parameter ... they can do that because method references are getting specialized so you can avoid boxing/unboxing for obvious cases, like passing integer/double constants. [EDIT] The MethodHandler from OpenJDK's invokedynamic proposal is a light-weight method reference, resembling System.Reflection.Emit.DynamicMethod from dotNet. MethodHandler will be used for call-sites and I think MethodHandler also gets reified. The thing I don't like about the JVM are the inconsistencies ... you've got primitive types, but you can't define your own. Arrays are reified (and now MethodHandlers too) ... but you have no way to have your own reified generic data-structures. Still ... in the long-run I think the JVM is a better platform than .NET ... if only Oracle would not stagnate it (or maybe now that it's open-source, some fork might be in order ... but I don't think it's doable unless it's a big company with lots of resources ... maybe Google, but I'm not holding my breath).
  - brehaut 16y ago
    > Interesting ... can you find technical details on that? ... Unfortunately not; mostly comments in passing on IRC or in videos. That DLR (and invokedynamic) stuff sounds really clever, if you've got any related links i'd be interested in reading more.