4 ms·

> Higher-kinded I made small research and I see higher-kinded types very similar to generics, what is the main difference? > union types You have Multiple In

• lmm 10y ago
  > I made small research and I see higher-kinded types very similar to generics, what is the main difference? Higher-kinded types mean you can have type parameters that are themselves parameterized. E.g. in Java (or Kotlin) you can do interface MyType<T> { T something(); } and you can have a MyType<List<String>> where something() returns List<String>. But you can't do interface MyType<T<_>> { T<String> something(); T<Integer> somethingElse(); } and have a MyType<List> where something() returns List<String> and somethingElse() returns List<Integer>. > You have Multiple Inheritance in kotlin, which does more or less the same. Only if you control the classes involved, and most of the time you don't - I can't see any way to create a union where one of the types is from an external library, not even by making them both subtypes of a common interface. (Particularly frustrating since Kotlin supports extension methods, which have all the same complexity for the reader, but as far as I can see you can add a method to a library type but you can't add an interface onto it). (Also Ceylon's native union types are nicer than subtypes). > I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too. What I mean is, real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML. E.g. Spring/Guice, Hibernate/JPA, Jersey, Jackson, Quasar... . It's worth saying that this happens for a good reason: Java isn't expressive enough to practically express functionality that people need, and thus they resort to using these techniques instead (the realistic alternatives are callback hell, dropped transactions, copy-pasted code...). But HKT (and related/similar functionality) give you enough expressiveness to replace these things with plain old code.
  • jorgemf 10y ago
    Thanks for the explanation. I think higher-kinded types is one of those things that make me not like Scala. I cannot think about an use case, but there should be few. > Only if you control the classes involved You see it like a problem, I see it like a good practice. You should do whatever you want with code that wasn't meant for something else. There were a long discussion in the kotlin forums about this. > real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML I see this in Python, Ruby and other languages. Real-world codebases are similar. It is clear we think different and we are not going to agree, but I liked the conversation and I learnt new things on the way. Thanks
    • lmm 10y ago
      > I cannot think about an use case, but there should be few. Once you're used to having them in the toolbox you use them all the time. > You see it like a problem, I see it like a good practice. You should do whatever you want with code that wasn't meant for something else. Would you say your classes shouldn't have fields that are third-party library types? Having variants that are third-party library types is just the converse. > I see this in Python, Ruby and other languages. I can't speak to Ruby but I have Python experience. springpython is seen as a joke. Python decorators are actual Python functions written in normal Python, not hints to some magic framework that does the actual implementation. Metaclasses are problematic but they don't break the rules of the language to anything like the same extent as happens in the Java world.