I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…
Clean Code vs. A Philosophy Of Software Design
91–100 of 554 posts
Re: Clean Code vs. A Philosophy Of Software Design
#92Most programmers know about this in 2025 but they didn't back then. Looks like the authors don't even mention it.
Re: Clean Code vs. A Philosophy Of Software Design
#93Earlier quoted context omitted.
I don't see how it is uncle Bob's fault that your friend misunderstood his book.
Judging from this thread, it seems like a lot of people have similar issues with UB's work.
Re: Clean Code vs. A Philosophy Of Software Design
#94Earlier quoted context omitted.
> It was always like that. And Fowler the same thing with his criticism of anemic domain model. What leads you to disagree with the fact that anemic domain models are an anti-pattern? https://martinfowler.com/bliki/AnemicDomainModel.html I think it's obvious that his critique makes sense if you actually take a moment to try learn and understand what he says and where he comes from. Take a moment to understand what ca…
"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts
See, this is the sort of lazy ignorance that adds nothing of value to the discussion, and just reads as spiteful adhominems.
Domain models are fundamentally an object-oriented programming concept. You model the business domain with classes, meaning you specify in them the behavior that reflects your business domain. Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. In Domain-Driven design, with its basis on OO, you implement these operations at the class level, because your classes model the business domain and implement business rules.
The argument being made against anemic domain models is that a domain model without behavior fails to meet the most basic requirements of a domain model. Your domain model is just DTOs that you pass around as if the were value types, and have no behavior at all. Does it make sense to have objects without behavior? No, not in OO and elsewhere as well. Why? Because a domain model without behavior means you are wasting all development effort building up a structure that does nothing and adds none of the benefits, and thus represents wasted effort. You are better off just doing something entirely different which is certainly not Domain-Driven design.
In fact, the whole problem with the blend of argument you are making is that you are trying to push a buzzword onto something that resembles none of it. It's like you want the benefit of playing buzzword bingo without even bothering to learn the absolute basics of it, or anything at all. You don't know what you're doing, and somehow you're calling it Domain-Driven design.
> Why would focusing on OO be a goal?
You are adopting a OO concept, which the most basic traits is that it models business domains with objects. Do you understand the absurdity of this sort of argument?
Re: Clean Code vs. A Philosophy Of Software Design
#95I don't like the guy very much, but for web development even just mostly following Clean Architecture does so much to keep things from devolving into chaos long term.
Re: Clean Code vs. A Philosophy Of Software Design
#96Earlier quoted context omitted.
> It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript It was always like that. And Fowler the same thing with his criticism of anemic domain model. But software-engineering is no exceptions to having a mass of people believing someone without thinking by themselves.
> It was always like that. And Fowler the same thing with his criticism of anemic domain model. What leads you to disagree with the fact that anemic domain models are an anti-pattern? https://martinfowler.com/bliki/AnemicDomainModel.html I think it's obvious that his critique makes sense if you actually take a moment to try learn and understand what he says and where he comes from. Take a moment to understand what ca…
Yes, exactly. And this "classical" object-oriented programming is an anti-pattern itself.
(That being said, OOP is not well defined. And, for example, I have nothing against putting related data structures and functionality into the same namespace. But that's not what OOP means to him here)
Re: Clean Code vs. A Philosophy Of Software Design
#97Earlier quoted context omitted.
"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts
> "It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. See, this is the sort of lazy ignorance that adds nothing of value to the discussion, and just reads as spiteful adhominems. Domain models are fundamentally an object-oriented programming concept. You model the business d…
They are absolutely not. In fact, they are not even specific to even just programming, let alone OOP.
Re: Clean Code vs. A Philosophy Of Software Design
#98It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be ap…
> It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be…