In order for that to be a testable prediction the terms need to be made precise. OO is a famously vague concept with many different concrete incarnations. There

In order for that to be a testable prediction the terms need to be made precise. OO is a famously vague concept with many different concrete incarnations. There's single dispach vs multiple dispatch. Within single dispatch you have prototype based vs class based. You have objects as a record of closures. With multiple dispatch you have dispatch on class, or predicate dispatch, or full pattern matching. There's the question whether some form of identity or state is part of OO. The concept is broad enough that you can easily stretch it so that almost any modern language is OO in some form. A functional or logic programming language where functions can be split into multiple cases with pattern matching is arguably just a generalization of predicate dispatch. If on the other hand we restrict the term to languages where values are essentially identity + a record of methods (whether through the indirection of a class v-table or directly stored in the value as in prototype based languages), I do think that model has largely run its course. It will certainly remain popular in the near future, but people are increasingly realizing that modeling everything as a record of methods + identity (+ state?) isn't a good way to do it. There are certain things that lend themselves to that way of modeling, but most things are best modeled in some other way. Records of functions + identity is just one particular data type among many, and it's not any more special than any other data type. Modeling everything as an object is like TCL where you model everything as a string. OOP is nice on the surface because you have some vague analogy to real world objects, but that does more harm than good. It is similar to agile or TDD where people try to sit down at the computer and immediately start typing code without any careful thinking beforehand. Like TDD and agile, OO also facilitates that kind of programming because people can take the concepts in their head and immediately start typing class definitions. It works for easy problems, but even there it does not lead to a pretty end result (one of the symptoms that sticks out most is the question 'on which class does this method belong?'). Rather than designing your program to model the real world, it usually works much better to design your program around the problem you're trying to solve. Rather than starting with the real world and making an analogue to it in your program, you start with the problem you're trying to solve and come up with a data model that facilitates solving that problem. A famous example of the former style gone wrong is Ron Jeffries who tried to write a sudoku solver with an OO + TDD approach in a series of blog posts. He modeled his program with classes that seem natural for the problem, and he wrote tests for those. Unfortunately writing a sudoku solver is not one of those problems where you can just start banging out code without any thought and get it to work, so he got stuck because he did not think about how to actually solve the problem, he only thought about how to model the real world with OO.