Even as a relatively young† programmer, I’m with you to a certain extent. OOP‡ is both technically and philosophically unsound.
However, though I use C quite a bit, I don’t think procedural programming is the paradigm to end all paradigms. My knowledge, productivity, and code quality have all benefited from functional programming (Haskell and Scheme) and generic programming (C++).
Also, splitting up functionality is a part of good abstraction, and “weird ways” might only appear weird because you’re unfamiliar with them. That’s how I felt for a while about monads, for example. Some of it is just having the experience to see what qualities make code good in a particular paradigm. And regardless of paradigm, good abstractions are essentially about factoring and reducing repetition (DRY).
†though not terribly new
‡the “classes and inheritance” kind that Java epitomises
Philosophically? Can you please elaborate on this? Technically, I don't think there is any unsoundness in OOPs as compared to functional programming (or procedural or generic). Technically, there are paradigms available for all requirements. It might end up being messy or boring or bloated, but that is not a technical issue but more human. OO code on the other hand is incredibly easy to grasp and the ubiquity of OOP fuels itself. May be we would have been at a higher level in our enterprise codes if we had chosen a superior language like Haskell, Scheme or Python for everything; but we don't it for sure. Code is as much an art as it is science, and sometimes better art is possible with outdated paradigms likes paint and paper than touch interfaces and brilliant applications.
As mappu mentioned, I was inadvertently paraphrasing Alexander Stepanov, who said it better than I can:
“I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting—saying that everything is an object is saying nothing at all.”
Most of my work has been in game dev and languages, so I may be biased, but the problems I encounter tend to be about 90% dataflow, constraint satisfaction, events, and logic programming, and 10% sequential/imperative code to string it all together. OOP (again, in the Java sense) can model the non-sequential parts, but it’s just sort of awkward and unpleasant.
“I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras—families of interfaces that span multiple types.”
“I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms—you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.”
You can’t come up with an interface until you know that it actually corresponds to anything. The defining feature of OOP is also its greatest weakness: that it bakes interfaces into datatypes. Modularity is crippled and change is prohibitively difficult, resulting in extensive workarounds (and a proliferation of design patterns).
But ultimately, programming is about what you create with it. We can argue about languages and paradigms all day, or we can just make cool stuff however works best for us.
I believe the GP is quoting[1] from Alexander Stepanov (author of the C++ STL).
Saying "pick the right paradigm for the task" is of course the correct answer, but it's fun to argue sometimes, and OOP is definitely overhyped in certain markets (for instance, university CS)
Yes, I was (somewhat accidentally) paraphrasing Stepanov. It’s been a while since I read that.
But actually, I think “pick the right paradigm for the task” needs the qualification of “…within your other constraints”. The most expressive language for a job might not work in your situation—whether for reasons of efficiency, of maintainability (i.e., finding maintenance programmers), or of interoperability with the rest of your stack.
However, though I use C quite a bit, I don’t think procedural programming is the paradigm to end all paradigms. My knowledge, productivity, and code quality have all benefited from functional programming (Haskell and Scheme) and generic programming (C++).
Also, splitting up functionality is a part of good abstraction, and “weird ways” might only appear weird because you’re unfamiliar with them. That’s how I felt for a while about monads, for example. Some of it is just having the experience to see what qualities make code good in a particular paradigm. And regardless of paradigm, good abstractions are essentially about factoring and reducing repetition (DRY).
†though not terribly new
‡the “classes and inheritance” kind that Java epitomises