4 ms·

"Dynamic types are, at their core, there to remove the incredible tedium of things like generics or templated types."

• jimmaswell 7y ago
  I've never felt like templated types or generics are tedious.
  • viraptor 7y ago
    Considering the time when it was written, it could mean for example Java's ridiculously long generic declarations which couldn't be inferred or aliased. Things are much better and more ergonomic these days. Specific example - some languages will allow you to do: fun f(x: int): // return type inferred var foo = something(x) return foo While others need (including type erasure getting in the way): Complete<Version<Of<Generic, Foo>>>> f(int x) { Complete<Version<Of<Generic, Foo>>>> foo = (Complete<Version<Of<Generic, Foo>>>>) something(x); return foo; }
    • dvlsg 7y ago
      I agree, I quite enjoy them in TypeScript where I rely heavily on inference. I suppose it helps that the types aren't strictly required too, so you can side-step them if necessary.
    • jimmaswell 7y ago
      Type erasure was one of the worst decisions in Java, yeah. Generics and working with types in general is great in C#.
      • zzygan 7y ago
        Disagree. Type erasure is actually one of th best possible decisions made by the java designers. Languages that have higher kinded types (Haskell, Scala)are virtually impossible to implement without type erasure. This is why the .net runtime doesn’t have languages with HKT
        • mruts 7y ago
          Could you elaborate? How does type erasure relate to HKT?
          • viraptor 7y ago
            Yup, that doesn't seem to be a real restriction. Here's a comment on a roslyn issue for dotnet: https://github.com/dotnet/roslyn/issues/2212#issuecomment-98500288 https://github.com/dotnet/roslyn/issues/2212#issuecomment-98... > Of course it could be implemented type-erased style, but that's an unpleasant can of worms. > If it were implemented like C++ templates, it would be a source level feature, meaning you can't have higher kinded polymorphic methods in assemblies. I think we can reach consensus that such a feature would only pollute the language. > If it were implemented like Java generics, it would lead to all sorts of nonsense. For example you couldn't do typeof(M<>) inside the hkpm, since the type has been erased. And then a complex-but-good implementation idea follows. Type erasure is not necessary in this case.
            • zzygan 7y ago
              The complexity is exactly is issue. So while it’s possible to implement on the .net runtime without type erasure, it’s hard. Plus the only reason type erasure is bad is if you want reflection. Which in FP languages with a solid type system isnt idiomatic and safe anyway. Edit: value types are one other reason for not using erasure but Can be done other ways
        • jimmaswell 7y ago
          I don't see how the absence of type erasure could possibly be a restriction. Cast everything to object if you must. I've literally never run into a situation where I wished type erasure was there but didn't have it, but I've ran into situations where type erasure caused problems in Java and where the absence of type erasure let me do things the way I wanted in C#. typeof(T), new T[], new T(), default(T), etc.
          • lazulicurio 7y ago