4 ms·

Most "complaints" about generics in Java have to do with type erasure. It's a tradeoff at the end of the day, it opened up the JVM to host many high quality lan

by azth 5y ago

Most "complaints" about generics in Java have to do with type erasure. It's a tradeoff at the end of the day, it opened up the JVM to host many high quality languages like Scala, Kotlin, Clojure, etc. Haskell also does type erasure as far as I'm aware. Furthermore, the JVM is now getting generic specialization for value types, so types like HashMap<int, Object> become viable without the cost of boxing. Inheritance based languages enable covariance and contravariance in generic types, something that comes in handy in many occasions.

josephcsible 5y ago
If a language erases all types, like Haskell, it's fine. If a language doesn't erase any types, like C#, it's fine. If a language erases types in some places but not others, like Java, you get all sorts of awful problems.
- azth 5y ago
  Could you provide examples of such? I'm not aware that the Java team mentioned any when positing the primitive specialization design.
valyagolev 5y ago
“Haskell also does type erasure as far as I'm aware.” It’s not exactly an applicable term. Indeed Haskell doesn’t let runtime bother with a lot of information that it can provably dispense of. But there’s no laxity tradeoffs as in Java, Haskell won’t let you use a wrong type in a container
- azth 5y ago
  > Haskell won’t let you use a wrong type in a container Could you elaborate? Java should throw a runtime exception for mismatches.
  - josephcsible 5y ago
    The key word in your post is "runtime". Haskell will prevent that bug at compile time instead.
    - azth 5y ago
      Actually, I was thinking of covariant arrays. The compiler should prevent issues at compile time for generic collections, same as Haskell.
    - kaba0 5y ago
      That’s false. Java’s generics are sound, you can’t introduce runtime type errors without casting (which is also true of haskell)
      - TheDong 5y ago
        As a pointless pedantic nit, Java's type-system is unsound: https://io.livecode.ch/learn/namin/unsound https://io.livecode.ch/learn/namin/unsound But realistically, the above doesn't matter. What actually matters is that you often _do_ have to cast at runtime in java, so it's somewhat common to hit type errors at runtime in practice. Haskell's type-system makes runtime type casting both less necessary, and vanishingly rare, meaning such runtime cases are practically never hit. The above is at least true from my personal anecdotal experience.
        kaba0 5y ago
        As far as I know that unsoundness “hack” no longer work. Hm, could you please show me where you had to cast? Long ago, some resource/service lookup did require casting, but my anecdotal experience is that there really is no common area where I have to cast anything anymore.

by azth 5y ago

josephcsible 5y ago

If a language erases all types, like Haskell, it's fine. If a language doesn't erase any types, like C#, it's fine. If a language erases types in some places but not others, like Java, you get all sorts of awful problems.

azth 5y ago
Could you provide examples of such? I'm not aware that the Java team mentioned any when positing the primitive specialization design.

valyagolev 5y ago

“Haskell also does type erasure as far as I'm aware.” It’s not exactly an applicable term. Indeed Haskell doesn’t let runtime bother with a lot of information that it can provably dispense of. But there’s no laxity tradeoffs as in Java, Haskell won’t let you use a wrong type in a container

azth 5y ago
> Haskell won’t let you use a wrong type in a container Could you elaborate? Java should throw a runtime exception for mismatches.
- josephcsible 5y ago
  The key word in your post is "runtime". Haskell will prevent that bug at compile time instead.
  - azth 5y ago
    Actually, I was thinking of covariant arrays. The compiler should prevent issues at compile time for generic collections, same as Haskell.
  - kaba0 5y ago
    That’s false. Java’s generics are sound, you can’t introduce runtime type errors without casting (which is also true of haskell)
    - TheDong 5y ago
      As a pointless pedantic nit, Java's type-system is unsound: https://io.livecode.ch/learn/namin/unsound https://io.livecode.ch/learn/namin/unsound But realistically, the above doesn't matter. What actually matters is that you often _do_ have to cast at runtime in java, so it's somewhat common to hit type errors at runtime in practice. Haskell's type-system makes runtime type casting both less necessary, and vanishingly rare, meaning such runtime cases are practically never hit. The above is at least true from my personal anecdotal experience.
      - kaba0 5y ago
        As far as I know that unsoundness “hack” no longer work. Hm, could you please show me where you had to cast? Long ago, some resource/service lookup did require casting, but my anecdotal experience is that there really is no common area where I have to cast anything anymore.