Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

91–100 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#91
post #74

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…

Let's not forget that Uncle Bob, by the time of writing "Clean Code" had 4 decades coding experience.

Re: Clean Code vs. A Philosophy Of Software Design

#93
post #87

Earlier 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.

It might just be that the divide of a getting-things-done developer and a bloat developer isn't really caused by Uncle Bob but merely correlates with it. I.e, good developers also agree with Uncle Bob, though apparently with a different interpretation of what he said.

Re: Clean Code vs. A Philosophy Of Software Design

#94

Earlier 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

> "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 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

#95
I find it funny how much people obsess over Clean Code. In my opinion Robert Martin's Clean Architecture is a much more valuable and realistic idea than all this madness about 3 line functions, no comments, do one thing, etc. I would take the ugliest code that followed Clean Architecture over any "Clean Code" that didn't bother sensibly separating business logic and I/O.

I 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

#96

Earlier 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…

> it's not object-oriented programming. That's it.

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

#97

Earlier 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…

> Domain models are fundamentally an object-oriented programming concept

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

#98
post #4

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 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…

Code like Uncle Bob suggests is not easier to read and understand, it is harder, IMO and that of many others. Since the disagreement starts from this any further discussion is impossible.
Post reply on HN