| 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. |