[bryal]

> OCaml added an object system to ML. CommonLisp added an object system to lisp. Haskell added TypeClasses. Scala is an attempt at an Haskell like language with a full object system. F# and Kotlin both have object systems as well. One could argue actors are a purer form of OO. And so on.

Haskell type classes have nothing to do with OOP in the least, and as far as I know, Ocaml is a counterexample rather than an example to your point: they included OOP becsuse it was all the hype at the time of conception, but the OOP features are really quite unpopular today.

As you were completely off with Haskell, I can't exactly trust that you're right about any of the other languages "running back to OOP". If anything it seems to me the languages that started out as multi-paradigm FP/OOP have become more purely FP over time, as OOP has failed to prove its worth.

[pjmlp]

> Haskell type classes have nothing to do with OOP in the least, and as far as I know

They surely do, OOP like FP, is very fuzzy and since the Simula/Smalltalk days there have been multiple ways to try to represent OOP concepts.

There isn't any OOP language that implements every OOP idea, just like there isn't any FP language that implements every FP idea.

Type classes allow for polymorphism, and combined with modules one can make use of module private implementations for the encapsulation part.

Extensibility can be achieved either by having a type implement multiple type classes, COM v1..vn style, or by delegation.

[bryal]

Depending on your definition of the term, OOP can imply parametric & ad hoc polymorphism. Sure. But that in no way implies that all languages with that kind of polymorphism are OOP. That's gotta be, like, the first logical fallacy one learns about...

By your logic: 1. Ducks have feathers 2. All birds have feathers 3. Therefore, all birds are ducks

In any case, Haskell didn't get its polymorphism from any OOP language, so the point is moot. ML was first to introduce parametric polymorphism in 1975 — Java/C#/etc with their "generics" came later. Even ad hoc polymorphism with type classes was proposed 7 whole years (1988) before Java was even released (1995). And sure, the paper mentions that OOP has to solve similar issues, but "solving the same problem" ≠ "being the same solution".

[tome]

> > Haskell type classes have nothing to do with OOP in the least, and as far as I know

> They surely do

That misses the point. The original challenge was

> > Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP

and didibus offered

> Hum, I think most did ... Haskell added TypeClasses

But that's simply not true that Haskell added type classes as an attempt to run back to OOP.

[pjmlp]

Well all the FP languages without any kind of OOP like features, are doomed to stay as academia research projects, so.

[tome]

Yes, if you define OOP-like broadly enough, that is surely true.

[didibus]

That's my point. We should discuss the specifics and stop generalizing.

For example, OO has polymorphism as a core idea. TypeClasses are an implementation of ad-hoc polymorphism. This concept is a core part of OOP as well as all practical FP languages.

Now if we talk about OOP being bad, and we start talking about ad-hoc polymorphism. That's actually a great concept. It's one of the best concepts to appear in programming languages. So here we are talking about something great which most OOP languages have and make a core part of their offering. Something which Haskell also has and makes a core part of its offering.

Now you can try to move the goalpost, say nah, OOP doesn't mean ad-hoc polymorphism... okay what does it mean then? And maybe you mention class inheritance. Okay, is that it? What about abstraction, data encapsulation, overloading, access scopes, data instantiation, polymorphism, message passing, information hiding, actor-concurency, user defined types, etc. ?

So if you meant to say that inheritance is bad, then say that inheritance is bad. But even here, TypeClasses support inheritance?

> Haskell also supports a notion of class extension. For example, we may wish to define a class Ord which inherits all of the operations in Eq. [...] Note the context in the class declaration. We say that Eq is a superclass of Ord (conversely, Ord is a subclass of Eq), and any type which is an instance of Ord must also be an instance of Eq.

From: https://www.haskell.org/tutorial/classes.html

So what now? Maybe we actually mean that field inheritance is bad? Or what is it? And that's the kind of technicalities we should be discussing, not just say OOP bad, FP good.

[tome]

Subclass polymorphism in typical OO languages (Java, C++, Python) is nothing like type class polymorphism. Class inheritance is nothing like type class sub/superclassing.

It's quite possible for one to be good and the other to be bad (and I would claim that is indeed the case).

[pjmlp]

Just as broadly as FP can be defined.

[didibus]

It is hard to trace back the timeline history of all these things, especially as programming languages and their associated paradigms didn't evolve in a vacuum.

With that said, I would say some people would agree that operator overloading and ad-hoc polymorphism are core features of OO languages. In fact, many people learn first about ad-hoc polymorphism through an OO language, such as learning about Java Interfaces or Traits in Ruby.

So in that sense, TypeClasses do relate to OO.

This is where things get muddy. What is OO, what is FP? If you keep yourself stuck in the taxonomy you'll never leave it, because choosing labels is a subjective process. You can put the boundary wherever you want, there is no success criteria.

That said, there are real concentre ideas and implementation strategies. Those are more interesting, but don't get talked about very often.

Some of OOs main features:

- Data encapsulation

- Polymorphism

- Behavior abstraction

And Haskell similarly puts a lot of emphasis on those same features.

So what does one mean if they say OOP is bad? That those features are bad? That would transitively imply that Haskell similarly emphasises bad features?

Now I don't know about everyone, but that's not what I mean if I criticize OOP, I'm not claiming to avoid polymorphism, to get rid of behavior abstraction, and to stop trying to encapsulate data.

So the question is, what's wrong with OOP then? And this is where you'll see that things get nuanced and detailed oriented. And that it's not everything that is wrong, only certain specific things are not ideal and might have better solutions.

And at that point, you can't even speak of OOP generally, you need to speak of specific languages. For example, you could argue that Haskell TypeClasses are a better way to implement ad-hoc polymorphism than Java Interfaces. But someone could say that Self's Traits are just as good if not better than both of those approaches. Etc.