> I think it's lazy to dismiss the OOP as hate from experts who are complaining

I'm sorry if this is what you understood. The hate is from people hearing the complaints of experts. The experts generally have great understanding of the pros and cons, and are aware of the weaknesses, which they will openly talk about and sometimes that will make it sound worse, almost hyperbolic to others. Even I'm faulty of doing this, I might say this just sucks, or it's total rubbish, but really I mean it's pretty good and there's a lot of good ideas and parts, just needs some refinement and a few modifications because there are still problems with it, and I just faced one such wart so I'm frustrated and writing a big blog post to complain about it.

And this is the source of the misunderstanding. Overreaction and hyperboles from experts, taken at face value to those who are learning about it.

To your other points, I think it's interesting you bring up React since its biggest competitors: Vue, Svelte and Angular are all OO based and seem to be doing well.

> 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

Hum, I think most did. 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.

See, my point is that experts only ever complained about certain aspects of current iteration of so called OO programming languages. And as you can see, alternate languages they'd reach for or newer languages after them (or even newer version of those languages) all tried to address those shortcomings, but did not throw the baby out with the bathwater. There is convergence of ideas, and most of those languages have many if not most of the OO staple feature set, while having taken a few out or added some other inspired often by FP, but sometimes by other paradigms too.

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

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

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

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

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

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

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.

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

I'm talking about ad-hoc polymorphism, for example, in Java it would be interfaces and interface inheritance.

I believe in OO this concept comes from Self from 1987, where they first implemented Traits. In Standard ML TypeClasses were introduced in 1988 I believe. So it actually seems that OO would have had a form of ad-hoc polymorphism before ML. Now I don't want to debate where the ideas came from, I'm trying to say the "camps" are stereotyping which shouldn't be brought up in a technical conversation. Traits and TypeClasses share the same fundamental idea and purpose, and Haskell TypeClasses is its own variant of that idea, which is slightly different to Standard ML TypeClasses as well, and to how other FP languages do ad-hoc polymorphism, and in OO languages there are many variant on that idea as well.

If you define "OO" to mean "has any form of ad hoc polymorphism" then I agree that Haskell is an OO language. On the other hand, I suspect most of the profession would assume that the polymorphism requirements in the definition of OO extend only so far as what Java, C++ and Python provide, that is, subclass-based polymorphism implemented using a vtable reference per object (or equivalent). The Haskell community certainly does not consider type classes to be a feature that provides "OO".

When I enter these debates I assume we're talking about OO in the de facto sense described above. Under that nomenclature I agree that ad hoc polymorphism is a useful language feature but believe that the OO implementation of it is bad.

This confusion of "what is meant by OO" is what my original comment was about.

The "hate" of OO is a misunderstanding, because most people are confused about what everyone and anyone even means when they talk about it, and that's also true of FP by the way.

So when someone criticizes OO for example, but their criticism is directed towards the fact that in Java, I cannot add methods to the existing HashMap class if I wanted too, and that annoys me. So am I criticizing OO? I'll probably label my article "Why OO doesn't work" or something like that. When I should have probably titled it: "Why it is a problem for Java classes to not be extendable from outside their class". Or at the very least: "Why subtyping for extension isn't always the most convenient mechanism for extension."

I see this happening not just on the topic of OO, but everywhere, and I find in a technical setting this is a dangerous thing to do.

I don't really know how to call this effect. I guess stereotyping is a good word for it.

And then there is prototype polymorphism (SELF, JavaScript), pattern based polymorphism (BETA), component based polymorphism (COM, SOM, UWP), protocol based polymorphism (Objective-C, Swift, Smalltalk), ....

That is the thing, there isn't one OOP.

how does smalltalk use protocols? is it more ad-hoc like "responds to selector" or something else?

That is one way, informal use of categories, if we limit ourselves to Smalltalk-80 and Squeak.

Pharo also offers traits, not sure if Cinacom and Dolphin also do it.

forgot about pharo, yes it has traits (protocols)

Just as broadly as FP can be defined.

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.

I like OCaml's and Common Lisp's OOP. I hate Java's OOP.

Yup, and what happens when you take one entity that has qualities you dislike and generalize it to all entities of the same color?

You get people hearing that OOP sucks, and they start to have fears and hatred towards it, thinking that all OO and every single idea and concept related to it is bad.

This is called stereotyping, and it's not productive to bring into a technical conversation. Even inside FP it exists, ever saw a Scheme programer and a Haskell programmer debate? They'd go on forever about whose the one true Functional Programmer.

>> I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts.

I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point.

Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all.

I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!”

>> Can you name

Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.

(going with the definition that frameworks are "your code gets called into by the community code" where libraries are "you call into the community code", please correct me if I'm wrong)

There are some very nice FP frameworks, for example Phoenix LiveView, or phoenix in general. Elixir has lots of mini-frameworks (like the Enum and Access protocols). They're a joy to work with and pretty easy to understand. I'm not really sure what constitutes a plugin, but I've written what I would consider "plugins" for the BEAM vm (loaded at runtime, with an exposed API behaviour called into by the system), and they're pretty smooth and easy to handle.

Arguably all of the BEAM OTP (std lib) and the patterns that packages expose for building persistent services are FP frameworks. If I may be permitted to make a more apples-to-apples comparison between the Erlang BEAM framework, to the BeOS C++ framework (both highly concurrent message-passing, actor frameworks). While I loved programming for BeOS, IMO doing everything functionally is far far smoother an experience than doing everything with objects. Both I enjoyed far more than programming the Dalvik (android) Java framework (though that was circa 2009).

Anyways having experience in all four quadrants, I don't think it's as simple as ("frameworks/plugins -> OOP; libraries -> FP).

Can anyone explain to me what the difference between a framework and a library is? I've looked it up several times but it always seems cloudy at best, and it seems like some things that are referred to as frameworks are pretty similar to some other things referred to as libraries.

My favourite explanation is that a framework calls your code, whereas for a library, your code calls the library functions. Does that make sense?

1. Framework owns your main() function. Using libraries you don't lose control of your main().

2. Hollywood principle. Library: you call us. Framework: we call you.

3. Frameworks are good for novices in certain paradigm because they guide along a standardised way to build apps. If you however find the framework's way not precise enough or its abstraction leaky then you will have a hard time escaping from the straightjacket.

Lot of frameworks actually are a combination of two things:

1. the actual "way of building apps"

2. useful library of functions

Lot of people would like to start with 1 and use 2 to guide them in the beginning, but drop 1 later on. Unfortunately frameworks couple 1 and 2 together very tightly making many people not even consider such frameworks.

1. None of the programming languages I use regularly have the concept of a main() function (not dismissing the point, just saying it's language specific). 2. Yeah, heard this one many times. It seems very hand wavy to me. 3. That's more a cost/benefit analysis than an explanation of the difference.

> Lot of frameworks actually are a combination of two things:

> 1. the actual "way of building apps" > 2. useful library of functions

This describes React pretty much spot on. And yet, React people are very determined to point out that it's React is a library, not a framework.

The hollywood principle is actually to me the definitive criteria. You plug your code into React and React ends up orchestrating and coordinating between your code, thus it is in charge of calling it and in what order etc.

That's normally what I would call a framework.

Now I don't know, maybe there's ways to use React only as a library, not sure if it would provide any benefit in that way.

Basically like when you call something like:

   Math.abs(-5)

That's a library call.

A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...

And what about React? If you search for "is React a framework" you'll come up with many, many people saying that it's a library. And yet, when writing a React app you absolutely have to structure your code a certain way.

Things can be both a library and a framework. You can use react like a utility and react itself can take have code injected in it.

I hear "I tried FP and learned a lot but it wasn't practical" all the time. Far more than the inverse.

There's probably a sampling bias, because of the attitude that one should learn Haskell "to be a better programmer". The FP universe is far broader than the pure FPs. Need I remind: Twitter went from RoR to Scala, ostensibly for practical (performance) purposes, though with hindsight they could have figured out how to scale RoR. So it's hard to argue that nobody has gone the other way strictly for "practical" reasons.

It's also hard to argue that Whatsapp hasn't been wildly successful at scaling to a billion users on a miniscule engineering team in spite of "impracticality of FP".

> So it's hard to argue that nobody has gone the other way strictly for "practical" reasons.

You've made explicit another confounding factor: a language is more than its syntax - you have to consider the entire ecosystem and constraints being operated under - including tooling and libraries

I think there are some subtleties hidden in the word 'practical'. There are differences between:

My company has 200 Java engineers, and a dozen systems written in Java; it's not practical to migrate everything to <FP language>.

Spring Boot solves so many things out of the box that I'd have to implement myself in <FP language>, which isn't practical.

FP has a lot of features but it's not practical to maintain a large complex codebase using those features.

> If you want a really good (non-individual) example, take React

React is probably not a good example, because it didn't really expose its users to the horrors of OOP. There wasn't much inheritance and subclassing going on in the userland; you didn't really see SecondaryButton component inherit from the Button component and override its "render" or "onClick" method. True, there were some such codebases, but it was extremely rare. So no, I don't think React users have ever experienced the full extent of OOP, where you have to hunt through your codebase up the hierarchy chain for the bit of code that is misbehaving.

I can tell you the one time I ever worked on a subclassed React component (large codebase too-- so it was a unique situation), it was not a joy.

Yikes I had a colleague years ago who was doing this, caused all kinds of fun bugs.

I can't think of an OOP framework that went functional.

I can't think of a time where we killed a project or rewrote a project to make it more functional. Or where OOP bite us.

React went functional for a reason. Does everyone share that reason?