4 ms·
I don’t really see any interoperability difficulty at all between C# and F# on the CLR, can you please be more specific? As far as I remember instead interopera
by tigershark 8y ago
I don’t really see any interoperability difficulty at all between C# and F# on the CLR, can you please be more specific?
As far as I remember instead interoperability between Java and Scala was quite a pain because of the different data structures.
- pron 8y agoThat's because both were designed to specifically work with how the platform is designed. But compare Python/C# and, say Python/Java or Clojure/Java interop and code sharing.
- tigershark 8y agoOk, then are you saying that the problem is that the authors of iron Python didn’t spend as much time and effort to integrate it in the .NET platform compared to the work that has been done with OCAML? From what I know it was actually Don Syme, the creator of F#, to bring non-erased generics in .NET. And if I remember correctly without his work on the generics it would have been more painful to have a nice interop between C# and F#. This seems quite at odds with your assertion that on the contrary erased generics make easier the interop between different languages on the same JVM/CLR.
- pron 8y agoAll I can say is -- it's complicated. When languages share much in common, then factoring stuff into the runtime can make things easier, but when they're very different, the more language-level assumptions you bake into the runtime the harder it is to share code. You want to strike a good balance between having a rich runtime that makes it easy to implement languages and not baking too much language semantics into the runtime, to make it easier to share code. In retrospect, I think that the tradeoff of not having generics reified at the JVM, causing a minor nuisance in Java but making code sharing and interop easier across a wide range of languages is a net gain.
- tigershark 8y agoI still can’t see any proof in your posts that using type erasure for generics makes easier to have interop between languages. And I can’t think about any single reason why that should be the case. Python doesn’t have at all the concept of generics. Why it should be any more difficult to implement interop between Python and a language with proper generics compared to a language with erased generics? For Python it will always be an object, and getting the result in Java or C# you will still need to cast it properly.
- pron 8y agoHere's an example: A Clojure list is a Java list, but Clojure is untyped. However, if you create a list of strings in Clojure, you can call any Java method that takes List<String> even though Clojure has no such concept. AFAIK, on the CLR, Python requires special treatment to call such a method. Also, Kotlin's and Java's variance strategy is very different. Nevertheless, Java's generic data structures are reused in Kotlin.
- tigershark 8y agoMmm.. ok, in iron Python you obviously need to specify the generic type that you are passing because it is needed to resolve the correct method, but in Java you wouldn’t. For me it’s a perfectly acceptable compromise if I can specify methods with the same signature and you can avoid passing around Class references to infer the type.
- pron 8y agoWhy do you need to pass around class references? That's exactly what I was saying about doing something wrong. In over 15 years of programming in Java heavily, I don't think I had to do that more than a couple of times.
- noelwelsh 8y agoAdding to the examples, Scala has declaration-site variance while Java has use-site variance. Erased generics allow the two to work together.
- noblethrasher 8y agoIt's worth noting that Don Syme also brought type erasure to the .NET platform via type providers, because provided types can be erased (and typically are, I believe). But, F# also lets the author of the type provider decide which class will be used to represent the erased type. So, unlike the JVM, and F# programmer can erase to something other than System.Object.