A major advantage of typeclass polymorphism vs dynamic polymorphism is that typeclasses enable parameteric polymorphism, and parameteric polymorphism enables reasoning that is lost if types can "pretend" to be a supertype.

For instance, in Haskell you can prove a functor instance has at most one implementation (if we disallow diverging values), uniquely given by fmap id === id. GHC can automatically derive it for you. If you have dynamic polymorphism this is lost because now you can have "nonuniform" functor instances that behave differently for different types while still satisfying the functor laws.

More generally, parameteric polymorphism eliminates a large number of "behavior surprises" that can lurk in OO code. And with existential types I never find myself missing dynamic polymorphism. Similarly, in Clojure, if I find myself using dynamic behavior, it's either to interact with Java or as a hacky version of parameteric behavior.

I don't understand your example. Is there an explanation for people who aren't Haskell experts somewhere?

> For instance, in Haskell you can prove a functor instance has at most one implementation

How would one do that?

I believe the technique is relational parametricity, but I don't actually know how to apply it in this case.

Correct me if I'm wrong, but isn't OO in OCaml frowned-upon, or at least not used frequently by seasoned programmers?

Not an OCaml programmer myself, but I heard this multiple times. For example, in Real World OCaml [ https://realworldocaml.org/v1/en/html/objects.html ]), and I quote from Chapter 11:

> You might wonder when to use objects in OCaml, which has a multitude of alternative mechanisms to express the similar concepts. First-class modules are more expressive (a module can include types, while classes and objects cannot). Modules, functors, and data types also offer a wide range of ways to express program structure. In fact, many seasoned OCaml programmers rarely use classes and objects, if at all.

To be fair, the chapter goes on to explain why you'd want objects. It also states they are very different from objects as understood by other OO languages. I'd say OCaml is therefore a bad example for OO.

--

How are type classes in Haskell an OO feature?

The fact that OO is not used frequently in OCaml does not mean that it is useless. Objects in OCaml are typed structurally, not nominally, i.e. object's type is the set of the methods it provides.

Consider an example:

  let a = object method f x = 1 end;;
  val a : < f : 'a -> int > = <obj> 

We define an object a, and the interpreter tells us that the type of the object is "< f : 'a -> int >", i.e. it provides method f.

Define another object

  let b = object method f x = 2; method g x = x end;;
  val b : < f : 'a -> int; g : 'b -> 'b > = <obj>  

Define a function that takes calls method f of its argument:

  let f obj = obj#f ();;
  val f : < f : unit -> 'a; .. > -> 'a = <fun>

The type of the function tells us that its argument must be an object that provides method f, and maybe some other methods. Now, we can call this function with object a, and object b:

  f a;;
  - : int = 1  

  f b;;
  - : int = 2 

This structural typing, (or if I'm not mistaken, it's called row polymorphism) is an interesiting feature of the language, and it may be useful in some situations. It does not harm the rest of the language, and I see it as a good feature that probably does not get a lot of attention, but it's theoretically solid and works well. Compared to more usual OO systems, it is cleaner and, imho, easier to reason about.

That said, I think, the authors of "Real World OCaml" are right, encouraging the use of Modules rather than Objects. But they do so primarily because in many mainstream languages the main means of abstractions are objects, and they are used for everything. OCaml has functors, modules, it has records, it has ADTs, it has functions, so the need for objects is very limited, and so the new users must get this message very clearly.

An article on objects in OCaml: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/

Awesome, thanks for the explanation!

I think I understand the appeal of structural typing: you are defining implicit anonymous interfaces as you write objects, and automatically grouping objects that share structure. But in which case is this more useful than, say, defining type classes or using explicit interfaces in mainstream OO languages? Or is it a case of preferences?

I can see a difference with objects: in most mainstream OO languages you cannot retrofit an object to comply with the interface you want if you don't control the source code and the object only differs from what you need on a triviality such as naming. But what about type classes? Isn't this what they are there for?

> How are type classes in Haskell an OO feature?

See https://news.ycombinator.com/item?id=8280613

There are so many ways of doing OO.

Depends on how you define OO. My own definition of object involves identity and corresponding encapsulated state, which is something that Haskell doesn't support directly (since identity isn't pure).

Sure, but given your backgound, I imagine you are fully aware that back in the early 90's the OO community was quite divided about what are actually the core concepts and their implementation.

So, what OO is all about will depend which researcher gets asked.

Oh, fully agreed. I think my main point was that OO in a language such as OCaml has very little to do with OO in a language such as Scala (or Java). I'm agreeing with the OP that the marriage of OO and FP in Scala is problematic.

Yes, we can use less currently mainstream (note: not less correct) definitions of OO, but that doesn't help the Scala=OO+FP position.

Just like languages have versions/revisions, e.g: C++11,C++14, Java8 ...etc, having versions at major changes during evolution of OO might have helped in creating reference points which can facillitate discussions and enhance understanding i.e. like OO98, 0099, OO2005 ...etc.

That's impossible, because what would you write in OOxx, given the different CS views and programming models on the subject?

Jump dump what is being worked on at any given point in time?

For me it is hard to grasp how youngsters see OO or FP, because I was part of the initial mainstream waves. So I got to see the things in a different perspective.

The world at companies was procedural, and lots of experimentation was going on.

True. And in the end, this even applies to functional or declarative programming

> So you don't use type classes in Haskell?

Sorry, how does this remark relates to my comment?

I assume it was intended to be 1) an assertion that type classes are OO, and 2) an implication that using them is mixing OO in your FP (which you said you don't like to do), and so 3) an allegation of inconsistency which should be clarified or examined.

There are a few places where this chain is weak.

> an assertion that type classes are OO

They never occurred to me as OO. Could someone explain this?

Sure, since I mentioned it.

Sorry if I misassume your OOP experience.

Many think about OOP as introduced by Simula/Smalltalk, or how it is served by Java/C#... ones.

However there are many other ways of doing OOP, which many of us in the old (early 90's) experimented with, while OOP was striving to become mainstream.

Type classes in Haskell and their use, can be easilly mapped to interfaces/protocols/traits/... in the OO world.

From the OOP point of view, type classes are a group of operations that can be applied to a given type and refereed to by a specific name.

Which allows writing polymorphic operations over types that support a specific a specific group of functionality.

Polymorphism and data hiding are the common concepts across all OOP proposals.

As for the remaining concepts, there are lots of languages that agree to disagree, between mainstream, academia and lost OOP battles.

And I can call one of the many Simon Peyton Jones talks that describe this, http://yow.eventer.com/events/1004/talks/1054, starting at 00:42.

To my mind, the biggest thing missing from typeclasses that you get automatically with many OO systems is a sense of persistent identity of objects. Of course Haskell has ways to roll your own, and I'm not sure the decoupling is a bad thing by any means, but it's a difference.

tnx. very insightful. I'm not fully convinced that type classes are OOP, but I certainly understand why --for a very broad definition of OOP-- one might think they are.

Yes.