> Have you considered that the non-OO designs are deficient in some way that prevents them from being used for the type of systems that you find to be examples of OO being bad?
Having shipped both significant non-OO projects and significant OO projects, their drawbacks were usually related to low adoption. In terms of code and architectural complexity, they were either comparable to OO projects (in specific situations), or better.
That being said, in most situations, language/paradigm choice were not the main drivers of project success. At worst, a bad OO codebase is a drag, not a killer, and the same is true with non-OO projects.
> Not that I am defending OO, I just want to know how you are differentiating between "OO produces complex systems" and "OO is used for complex systems".
OO definitely produces complex systems. And, let me be clear, by OO I mean the social consensus in OO circles, not the paradigm itself or the technical tools. My take is that OO circles host a cottage industry of consultancies and gurus peddling a stream of design patterns, advices, etc. which end up layering in any long-lived OO codebase and create unnecessary complexity.
>OO definitely produces complex systems. And, let me be clear, by OO I mean the social consensus in OO circles, not the paradigm itself or the technical tools. My take is that OO circles host a cottage industry of consultancies and gurus peddling a stream of design patterns, advices, etc. which end up layering in any long-lived OO codebase and create unnecessary complexity.
This right here. Every time I hear mid level dev bring up DDD I contemplate quitting and spending some time looking for a Rust or Clojure gig. Sometimes it gets so bad I think about biting the bullet and going to node.js
C# isn't a bad language, even the frameworks are taking a nice turn towards simplification (eg. ASP.NET Minimal APIs, EF direct SQL queries) but the culture it creates... LAYERS of bullshit :D
Absolutely! It is the misunderstanding and use of heavy abstraction, with "a class per file" that blows these systems into liabilities rather than solutions. Start with a low number of abstractions, as few as you can get away with given your requirements, and then only expand when the requirements change. It really doesn't matter the paradigm, it's possible to heavily abstract a functional system with various transformative functions that aren't truly needed until the data becomes more complex.
There is a whole industry peddling OO systems that are extremely abstracted for the benefit of filling chapters in a book, or producing extra pages of content in a website. I fell victim to both early on in my knowledge and even professional world, but somehow managed to follow what "felt right" and broke away from that to find an easy path forward that allowed me to use the tools I was given in the easiest way possible, and only introduce complexity when the solution was complex (not for the sake of complexity for complexity's sake).
Having shipped both significant non-OO projects and significant OO projects, their drawbacks were usually related to low adoption. In terms of code and architectural complexity, they were either comparable to OO projects (in specific situations), or better.
That being said, in most situations, language/paradigm choice were not the main drivers of project success. At worst, a bad OO codebase is a drag, not a killer, and the same is true with non-OO projects.
> Not that I am defending OO, I just want to know how you are differentiating between "OO produces complex systems" and "OO is used for complex systems".
OO definitely produces complex systems. And, let me be clear, by OO I mean the social consensus in OO circles, not the paradigm itself or the technical tools. My take is that OO circles host a cottage industry of consultancies and gurus peddling a stream of design patterns, advices, etc. which end up layering in any long-lived OO codebase and create unnecessary complexity.