As far as I&#x27;m concerned, the discussion I&#x27;m referring to started with this comment from realharo: &quot;Usually if you need a bunch of differently-typed objects to fulfill the same contract, you can just make them implement an interface&quot;.<p>The way I understood that is, if you have a f(a: A), and need to pass it a B and C, neither of which are subtypes of A, you can just create a new type D, have A, B and C extend D, and modify f to expect a D. My point was that it&#x27;s not always practical nor even possible to do so.<p>A type class would be a good way to abstract over the type itself and simply require a specific behaviour, but by the time you have f(a: A) where A is a concrete type, and you can&#x27;t modify f (because it comes from an external library, say), it&#x27;s too late to retrofit type classes into it.<p>As for your other point - type classes being awkward when you have multiple possible instances for a given type - I agree, but must say that I&#x27;m spoiled: my primary use of type classes is with Scala, where they&#x27;re just, when you come down to it, parameters to functions. You can let the compiler infer them when there is no ambiguity, but when you need to pass an int to a function that expects &quot;A with a monoid&quot;, you always have the option of being explicit about which monoid instance to use. I believe Haskell treats them as implicit parameters as well but without the option to pass them explicitly.<p>Finally, I&#x27;m afraid you&#x27;ve lost me with your last bit - reifying the instance we care about and passing the dictionary as a record. I wish I had something smart to answer, but I&#x27;m not sure I actually understand what it means. I know enough Haskell to be able to be able to read it (a necessary skill if you have even the slightest interest in FP), but not much more than that. Maybe if I knew more I&#x27;d have a clearer understanding of what you mean?