You must admit though, higher-kinded types are a good example of the kind of abstraction under discussion here.
Simply put, a higher-kinded type is a type that itself takes another type argument. For example, in Scala...* List[String] is a type, whereas List is a higher-kinded type You can then pass "List" to some method, and it would be parameterised and used to build a concrete List. You could alternatively pass the same method a "Set", or "Vector" to get the corresponding concrete collection in return. The basic concept is not at all difficult, though specifics of the implementation or the paradigm shift to a higher-level of abstraction when you work in this way across an entire codebase may cause some initial head scratching. Research in ways to improve the situation is, as ever, ongoing. My personal experience is that this kind of stuff actually simplifies my programs, by allowing me to strip out a lot of code duplication and/or tricky uses of reflection. YMMV, but unless you're explicitly using them to push the start-of-the-art in type system trickery then higher-kinded types don't add complexity. If you *are* pushing at the boundaries, then you only have yourself to blame :) * It's really not my intent to invoke Scala here, so don't make this a discussion about Scala, but Java can't express the concept (the closest it gets is raw types, which aren't the same thing at all). I just used the closest thing to Java that can manage this, and I'm obliged to stay at least within the Java *platform* where possible :) On Thursday, 8 December 2011, Fabrizio Giudici wrote: > On Thu, 08 Dec 2011 20:30:56 +0100, Josh Berry <[email protected]> wrote: > > > So.... how do you identify this added complexity? For example, are >> higher kinded types out of the question? It seems they work rather >> well for those that understand them. And I'm inclined to agree with >> them that anyone can learn them if they put forth the effort. My >> question is simply is it worth the effort? >> > > For your previous question I'd like to keep this argument out of my > answer. Discussing about the complexity of types will inevitably lead to > Scala :-) and I don't want to bring Scala (or any other language) into the > discussion now, because it's subjective (as you said, "they work rather > well for THOSE THAT understand them". I only mentioned facilities that > today are considered state of the art and rather orthogonal to most > languages, where I think everybody agrees that there are both things that I > was talking about: higher abstraction and higher complexity. > > > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > [email protected] > http://tidalwave.it - http://fabriziogiudici.it > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at http://groups.google.com/** > group/javaposse?hl=en <http://groups.google.com/group/javaposse?hl=en>. > > -- Kevin Wright mail: [email protected] gtalk / msn : [email protected] quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <[email protected]> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
