Even if you stuff the algorithms into the same type you have your data in (like most generic languages seem to encourage you to do), you still only have to type-cast/type-switch on getters and callbacks. And the only major missing requirement I can think of is that your nodes aren't guaranteed to be of homogeneous types (and you can hack that with a callback if you want).

Which is precisely why he wants generic types.

> "Consider your algorithms as functions which act on an interface."

How would he write a function that explicitly expects a graph whose nodes contain ints, and not, say, strings? What kind of interface would that function act upon?

> "you still only have to type-cast/type-switch on getters and callbacks."

The whole point is not having to do that.

class HashMap[A, B] extends AbstractMap[A, B] with Map[A, B] with MapLike[A, B, HashMap[A, B]] with HashTable[A, DefaultEntry[A, B]] with CustomParallelizable[(A, B), ParHashMap[A, B]] with Serializable

If that's what the type system is going to end up being with generics I'd rather just cast things. Sometimes less is more.

http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Class HashMap is parametrized over two types, A and B (presumably, key and value types). The rest seems to be implementation details, that play no importance unless you're going to actually use them. Just as integers are totally ordered, but unless you have use to that fact (i.e. comparing those integers), you can safely ignore that.

Same as with interfaces - if there's a interface Foo { ... } somewhere, you don't have to care your types implement it unless you're actually using it.

I just can't do anything like `data Tree a = Leaf a | Node [Tree a]` there.

(Edit: okay, my mind swayed a bit, that was trees, not graphs. I had different ideas on data structure to use, and my memories are a bit messy. Sorry about this. The problem should still hold, it applies to both trees and graphs, and I think many other data structures too.)