Why the focus on type classes? Yes, type classes can sometimes be very helpful (the Num, Monad and Functor typeclasses in Haskell for example - where would we be without them?)
But overuse of type classes in any language is an antipattern. Luke Palmer sums it up well in his blog post [1]
Advanced type system features have their place, but plain old functions go a long, long way. Functions are the masters of reuse: when you use an advanced feature, you need a yet more advanced feature to abstract over it. But all you need to abstract over a function is another function.
Using type classes where they're not appropriate leads to 1. writing unnecessary boilerplate code, 2. torturing the type system and 3. a slippery slope of adding more and more advanced type system features to bludgeon your poor design choice into the right shape. Use functions!
It's also worth reading Gabriel Gonzalez's post on a similar topic [2]
I think this point can not be stressed enough. Type classes have their place in day to day (Haskell) programming, but overuse quickly leads to bad abstractions that boil up from deep inside a codebase to all the way up to the public API.
My experience as a library author is that adding a type class for an additional layer of abstraction is easy and feels very natural. My experience as a library user is that understanding what problem the library author has solved using a type class can be very hard and confusing.
Comments
Why the focus on type classes? Yes, type classes can sometimes be very helpful (the Num, Monad and Functor typeclasses in Haskell for example - where would we be without them?)
But overuse of type classes in any language is an antipattern. Luke Palmer sums it up well in his blog post [1]
Advanced type system features have their place, but plain old functions go a long, long way. Functions are the masters of reuse: when you use an advanced feature, you need a yet more advanced feature to abstract over it. But all you need to abstract over a function is another function.
Using type classes where they're not appropriate leads to 1. writing unnecessary boilerplate code, 2. torturing the type system and 3. a slippery slope of adding more and more advanced type system features to bludgeon your poor design choice into the right shape. Use functions!
It's also worth reading Gabriel Gonzalez's post on a similar topic [2]
[1] http://lukepalmer.wordpress.com/2010/01/24/haskell-antipatte...
[2] http://www.haskellforall.com/2012/05/scrap-your-type-classes...
I think this point can not be stressed enough. Type classes have their place in day to day (Haskell) programming, but overuse quickly leads to bad abstractions that boil up from deep inside a codebase to all the way up to the public API.
My experience as a library author is that adding a type class for an additional layer of abstraction is easy and feels very natural. My experience as a library user is that understanding what problem the library author has solved using a type class can be very hard and confusing.