Fundamentally, this post conflates <i>type classes</i> with <i>functional programming</i>. Yes, type classes are one way that functional languages approach ad-hoc polymorphism (i.e. distinguishing which implementation of a function to use based on the types of its arguments.) This is not the only way to approach said problem. For example, OCaml has both objects and modules/functors to support ad-hoc polymorphism. That Scala and Haskell take a different approach to this problem does not make Scala "less" functional than Haskell.[1]<p>As usual, the real problem is one of terminology. If you take FP to mean "Haskell and Clojure", then one could easily find features of, say, Erlang or OCaml or Scheme that are "not FP." All of these are conventionally considered functional languages, and IIRC none of them—save Scheme-based ports of CLOS—feature multimethods or type classes. So, before nitpicking about whether a language is more or less FP, one should always clarify: <i>what do I mean by FP?</i><p>[1]: Not on its own, anyway; there are other arguments that can be made both ways, but this is not the space to make them.
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?)<p>But overuse of type classes in any language is an antipattern. Luke Palmer sums it up well in his blog post [1]<p><i>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.</i><p>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!<p>It's also worth reading Gabriel Gonzalez's post on a similar topic [2]<p>[1] <a href="http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/" rel="nofollow">http://lukepalmer.wordpress.com/2010/01/24/haskell-antipatte...</a><p>[2] <a href="http://www.haskellforall.com/2012/05/scrap-your-type-classes.html" rel="nofollow">http://www.haskellforall.com/2012/05/scrap-your-type-classes...</a>
No. (<a href="http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines" rel="nofollow">http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines</a>)<p>But seriously, I don't feel so, (though I came from writing Java). I like the protection of static typing, and haven't encountered yet anything that made the FP part suffer from the OO part.<p>p.s. if you haven't already, Martin Odersky himself is delivering a course named Functional Programming in Scala (still not too late to join) <a href="https://class.coursera.org/progfun-2012-001" rel="nofollow">https://class.coursera.org/progfun-2012-001</a>
It might be too basic if you are fluent, but I found it just in the right level for me. In any case, learning a language from it's creator seems to give you some insights.