Well, in the case of inheritance it's been widely considered an anti pattern for years now. In a way it's "deprecated" in favor of composition (composition over inheritance). Mostly because it tightly couples your objects in a tangled hierarchy that prevents useful reusability.
In the case on encapsulation, it turns out it makes little sense. Bind data and operations? Data is inert, it doesn't have agency. It's not a logical representation of concepts that you can work with. A chair doesn't change itself. But on a practical level, mutable states are an enemy of stability and predictability in code. That's why immutability has continuously grown in popularity as a practice and is a core concept of DDD. But if immutability is preferred, why encapsulate at all? You're not changing the bound (current) instance so you might as well cleanly pass data to a pure function and receive a changed dataset. And lastly, just about any OOP language provides reflection mechanisms that can be used to break encapsulation (so it's not much of a guarantee of anything).
There's a fairly famous quote about the downsides of inheritance (and it also hints at encapsulation as well):
“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang
I'm afraid in 2021 Erlang is a lot more "dead and buried" than encapsulation and inheritance. There's probably a good reason why it isn't in IEEE's top 50 programming languages, unlike Python, Java, C#, JavaScript and other gorilla-feeding jungles.
Functional programming is trendy and "beautiful" and "pure". OOP pays the bills.
Sure, but it's OOP that advocates composition over inheritance as well as immutability nowadays. It has nothing to do with functional programming, just a note that FP can do immutability better.
Also a note: unlike Java and C# which are fundamentally OOP, Python and Javascript are true multi paradigm languages - they can do FP just as much as the next.
In development, things tend to change.
"Advocates" is almost but not quite entirely unlike "deprecated". OOP provides different tools for different use cases and it's the developer's responsibility to use them appropriately. This is like "advocating" hammers over wrenches. Immutability is as useful as nails but there are situations where screws work better. FP has become Maslow's hammer of programming these days.
Not sure how you can argue FP "invasion" into Python and JS as neither were designed as OOP languages. Python grew into both little by little but Javascript was function first and only later sort of squeezed the idea of objects and even later provided the peppers means for using core concepts like encapsulation.
Neither was initially designed as FP. The use of the keyword "function" doesn't make a programming language "functional". I'm not an expert on Python but I've worked with JS since it was called Netscape Mocha/LiveScript. With the exception of functions as first-class objects (which few treated as such at the time) it was as procedural as FORTRAN. On the other hand, it was created with Sun's cooperation and under the strong influence of Java (and OOP in general) from day one. So yes, I can argue all day that FP in JS is a recent "invasion".
But that's largely irrelevant. My point is, inheritance and encapsulation are far from "dead and buried", they are important concepts which can be useful and profitable.
Nobody said they were design as FP. I say that JS was function-first as that was the main construct. Sure, you can say functions as first-class objects, which is truly a painful twist of concepts if that's what you want to see. I know people really wanted to force JS constructs into object-friendly usage patters (prototype, anyone) but it's a stretch to say there were Java "strong" influences back in the day. Objects are Java's code and there were no such things then (scoped variables protected/private/etc and funny inheritance was actually a composition of functions).
Thanks for sharing that article, though from my perspective it basically enforces my point. Inheritance defines relationships between objects (which prevents code reuse outside of a given project) and moreover, the author makes a great point that there's a right way to use inheritance. But that definition is his own convention outside if the definition of inheritance itself. Almost every developer of a given seniority has a theory and practice about the "right" way to use, despite the shortcomings on reliability and maintainability - some of which comes exactly from the need to enforce a set of arbitrary conventions about the right way to tackle inheritance. You need but a slip of code review to go down a slippery slope towards messiness (not to mention once you setup a hierarchy, nobody will ever be able to change it - there's a basic tenet to uphold agility in development practices that says "if you're face with two solutions to a problem, go with the one that's easier to change later on").
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
what do you mean by "dead"?
Well, in the case of inheritance it's been widely considered an anti pattern for years now. In a way it's "deprecated" in favor of composition (composition over inheritance). Mostly because it tightly couples your objects in a tangled hierarchy that prevents useful reusability.
In the case on encapsulation, it turns out it makes little sense. Bind data and operations? Data is inert, it doesn't have agency. It's not a logical representation of concepts that you can work with. A chair doesn't change itself. But on a practical level, mutable states are an enemy of stability and predictability in code. That's why immutability has continuously grown in popularity as a practice and is a core concept of DDD. But if immutability is preferred, why encapsulate at all? You're not changing the bound (current) instance so you might as well cleanly pass data to a pure function and receive a changed dataset. And lastly, just about any OOP language provides reflection mechanisms that can be used to break encapsulation (so it's not much of a guarantee of anything).
There's a fairly famous quote about the downsides of inheritance (and it also hints at encapsulation as well):
“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang
I'm afraid in 2021 Erlang is a lot more "dead and buried" than encapsulation and inheritance. There's probably a good reason why it isn't in IEEE's top 50 programming languages, unlike Python, Java, C#, JavaScript and other gorilla-feeding jungles.
Functional programming is trendy and "beautiful" and "pure". OOP pays the bills.
Sure, but it's OOP that advocates composition over inheritance as well as immutability nowadays. It has nothing to do with functional programming, just a note that FP can do immutability better.
Also a note: unlike Java and C# which are fundamentally OOP, Python and Javascript are true multi paradigm languages - they can do FP just as much as the next.
In development, things tend to change.
"Advocates" is almost but not quite entirely unlike "deprecated". OOP provides different tools for different use cases and it's the developer's responsibility to use them appropriately. This is like "advocating" hammers over wrenches. Immutability is as useful as nails but there are situations where screws work better. FP has become Maslow's hammer of programming these days.
My opinion is best expressed by Steven Lowe here
I'm sure (though have no data) that FP's invasive expansion into JS and Python correlates to the number of Erlang experts getting real-world jobs.
Not sure how you can argue FP "invasion" into Python and JS as neither were designed as OOP languages. Python grew into both little by little but Javascript was function first and only later sort of squeezed the idea of objects and even later provided the peppers means for using core concepts like encapsulation.
Neither was initially designed as FP. The use of the keyword "function" doesn't make a programming language "functional". I'm not an expert on Python but I've worked with JS since it was called Netscape Mocha/LiveScript. With the exception of functions as first-class objects (which few treated as such at the time) it was as procedural as FORTRAN. On the other hand, it was created with Sun's cooperation and under the strong influence of Java (and OOP in general) from day one. So yes, I can argue all day that FP in JS is a recent "invasion".
But that's largely irrelevant. My point is, inheritance and encapsulation are far from "dead and buried", they are important concepts which can be useful and profitable.
Nobody said they were design as FP. I say that JS was function-first as that was the main construct. Sure, you can say functions as first-class objects, which is truly a painful twist of concepts if that's what you want to see. I know people really wanted to force JS constructs into object-friendly usage patters (prototype, anyone) but it's a stretch to say there were Java "strong" influences back in the day. Objects are Java's code and there were no such things then (scoped variables protected/private/etc and funny inheritance was actually a composition of functions).
Thanks for sharing that article, though from my perspective it basically enforces my point. Inheritance defines relationships between objects (which prevents code reuse outside of a given project) and moreover, the author makes a great point that there's a right way to use inheritance. But that definition is his own convention outside if the definition of inheritance itself. Almost every developer of a given seniority has a theory and practice about the "right" way to use, despite the shortcomings on reliability and maintainability - some of which comes exactly from the need to enforce a set of arbitrary conventions about the right way to tackle inheritance. You need but a slip of code review to go down a slippery slope towards messiness (not to mention once you setup a hierarchy, nobody will ever be able to change it - there's a basic tenet to uphold agility in development practices that says "if you're face with two solutions to a problem, go with the one that's easier to change later on").