[revvx]

I don't think that's what happened.

Joe Armstrong was criticizing C++-style OOP when he wrote his critique.

After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP.

He didn't change his stance based on popularity. He changed his stance because in the 80s/90s the term "OOP" was synonymous with C++-style-OOP, but that changed in the 2000s thanks to 1) C++-style OOP criticism became commonplace in our industry (thanks to people like Joe Armstrong) and 2) an increase of popularity languages like Ruby and Objective-C (which are closer to Smalltalk) and even much-maligned concepts such as DCOM, SOA and CORBA.

[hota_mazi]

He doesn't even mention C++ in his essay [1], but regardless, the C++ OOP is pretty much the mainstream OOP, which we still use today in Java, Kotlin, C#, etc...

And... no, the change in mindset about OOP never happened. Kay and Armstrong's view of OOP never took on. Today, OOP is still not seen as message passing and mostly seen as polymorphism, parametric typing, classes/traits/interfaces, and encapsulation. The complete opposite of what Erlang is.

[1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

[revvx]

I'm the one mentioning C++. To anyone familiar with both styles, Joe Armstrong is clearly not talking about Smalltalk-style OOP in his essay, he's talking about C++/Java/etc style. And later on he only praised Smalltalk-style OOP.

And sorry, by a "change in mindset in our industry regarding OOP" I mean that it became commonplace to criticize C++-style OOP. Not that everyone stopped programming in that style. Maybe there's a better way to phrase it?

[alankay]

Again, please do your homework.

[tabtab]

"seen as" is the key here. "The masses" ultimately usually get to define terms, for good or bad. The gestalt or "feel" of what OOP "is" is often shaped by common languages and their common usage, again for good or bad.

It may be better to define specific flavors or aspects of OOP or OOP-ish things and discuss them in isolation with specific scenarios. That way the messy issue of canonical definition(s) doesn't come into play as often.

It would then be more of "hey, here's a cool feature of Language X or System X! Look what it can do...". Whether it's canonical or not is then moot.