While this may be true, it's missing the point. The claim that type classes are like interfaces (the usual argument is that they define an interface, but not an implementation) misleads OO-grounded programmers into thinking of type classes in terms of an already-familiar concept. This is bad because said programmers then attempt to apply familiar OO-styles, when they would be better off abandoning most of what they already know about design. I don't mean in the sense of "abstraction good, separation of processing good, repetition bad", but rather how to develop a useful/stable API, how to divide up the different processing the module should do, etc. In short, how to approach API design, which is very different in Haskell than the practice that most OO disciples are familiar with. IMHO, stating that type classes act like interfaces in argument types, but not return types, is too complicated a relationship to be useful to somebody's first introduction to FP. Better to avoid the whole issue completely. John Lato Alexey Romanov wrote:

Well, they act like interfaces in argument types, just not variable or return types.

Yours, Alexey Romanov