Fundamentally, this post conflates type classes with functional programming. 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]
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: what do I mean by FP?
[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.
Comments
Fundamentally, this post conflates type classes with functional programming. 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]
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: what do I mean by FP?
[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.