I believe that combining state and functionality - the root of OOP - is a mistake. Tons of programming patterns and concepts exist to solve this fundamental mistake. When you stop using classes all of your code becomes so much cleaner, easier to reason about, test, debug, and so on. You can never create only pure functions in the real world but you get closer to this ideal.
I stand by my statement that OOP is totally unnecessary.
You can believe that the world is flat, announce that boldly and stand by your statement. It doesn't mean it's true in reality, only that it's true in your mind.
Edit: This is more blunt than I intended it to be. For what it's worth, I happen to agree with you in principle, but I also think you're taking the roof off the car here and boldly claiming that the experience is so much better in the summer. What about winter? What about when it rains? What are the trade-offs? Not mentioning the downsides means that you either haven't found them, haven't thought about them or are intentionally omitting them from the discussion.
OOP is successful despite of itself. My point is it’s just an inferior way of programming and there is no reason to use it other than legions of OOP programmers who take it as gospel. Obviously this is an opinion but it’s informed by lots of experience in new and legacy code bases.
To be blunt, you are stating "opinions" without any basis in facts; hence it is hard to take you seriously.
Separation of Concerns, Modularization, Reusability, Type Hierarchies, Type Composition, Interface contract-based programming, Frameworks etc. were all made mainstream by OOD/OOP. These are things taken for granted by programmers today. As somebody who has been doing OOD/OOP since the early nineties i can tell you it was the single biggest reason for the explosion of Software in the past few decades.
As a concrete example, early in my career i had programmed in C using the Windows API; both 16-bit and Win32 (Thank you Charles Petzold). It was difficult, tedious and a lot of work. And then Microsoft introduced MFC (Microsoft Foundation Classes) Framework with Visual C++ IDE. With a few clicks of the wizard, i had a complete skeleton application with a lot of hard work already done for you. That was a revelation for me on the power of OOD/OOP. Things i had slaved over in Win32 was now at the fingertips of every noob who could type. The same revelation happened (but not to the same extent) when i moved from Xlib to Motif on Unix platforms.
I had pointed you to Bertrand Meyer's book OOSC2 (in my other comment) as the book to read to understand OOD/OOP. Another great book to study is Barbara Liskov and John Guttag's Program Development in Java: Abstraction, Specification, and Object-Oriented Design.
The major reasons software exploded are the internet and the ubiquity of computing devices that get cheaper, faster, and smaller. Language had nothing to do with it, with or without OOP.
I was formally trained and cut my teeth in OOP code bases and my latest company we are very light on classes. 99% is plain objects and modules that operate on them. Everything is very straightforward and logical. In my side projects I’ve stopped using classes as well and it’s so much cleaner.
This is opinion and preference. If I hired a guy who wanted to litter the code base with AbstractUserBeanFactoryFactories I’d have to let them go because it’s a situation I don’t want anymore.
>The major reasons software exploded are the internet and the ubiquity of computing devices that get cheaper, faster, and smaller. Language had nothing to do with it, with or without OOP.
This is putting the Cart before the Horse. Computers, Internet etc. can't do anything without the Software to drive them. That software is written in some Language/Tool using some Paradigms and Software Engineering principles. The ease of use, ease of structuring, ease of understanding etc. of these are what drives Creation, Adoption and Expansion of Computing and Devices.
>I was formally trained and cut my teeth in OOP code bases and my latest company we are very light on classes. 99% is plain objects and modules that operate on them. Everything is very straightforward and logical. In my side projects I’ve stopped using classes as well and it’s so much cleaner.
If you think merely using a syntactical structure like "class" (and Design Patterns) is what makes code OOP, then you don't understand OOP. You can do various degrees of OOP without language syntactical support. This is why i listed the principles and not some syntactic sugar in my previous comment. It is a way of thinking and Software Engineering which has given the most "bang-for-buck" so far in the Industry.
>This is opinion and preference. If I hired a guy who wanted to litter the code base with AbstractUserBeanFactoryFactories I’d have to let them go because it’s a situation I don’t want anymore.
Opinion and Preferences must be based on facts else it is only as good as "Flat Earther" category and nothing more can be discussed.
The idea is to make the functions pure and return the state ‘a(s_1) -> s_2, value’. Makes so much easier to test and write concurrent programs.
Though it’s not always practical, like when needing to push an element to an array for making updated state. It is nevertheless possible to shave of pure parts considerably making mutability easier to maintain.
I stand by my statement that OOP is totally unnecessary.