131–140 of 192 posts
This is Muratori showing he's a solo programmer who has only ever worked on relative small, simple software that runs on a single machine.
It seems like the main takeaway is that many textbook OO paradigms aren't the most optimized representations of the code. In this case, the cost is dynamic dispatch and pointer-chasing. This is a function of the Shape abstraction, but not the abstraction itself. But the argument is you're trading some of that performance optimization for maintainability. None of this is exactly news. And while I'm here ranting: I nev…
> In this case, the cost is dynamic dispatch and pointer-chasing. To sharpen your statement, the cost is missing the CPU caches, which is often caused by failing to pool allocations and reading indirectly. > But the argument is you're trading some of that performance optimization for maintainability. Right, but exactly how much? I would argue "very OOP" design styles neuter your ability to optimize the system, and so…
I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…
I worked with a guy who would constantly drop niche jargon and quotes from famous engineers and then kind of smugly look at you. He could not write a function without proudly saying what principals it was following. He was a horrible programmer, ended up getting laid off.
I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…
I think you’ve missed the point of clean code if this is your gripe with it. Every time you over scope a function signature, because you want to handle that other case, you add mental tax to the next person. This accumulates, burns time, and now confuses agents, which is time and tokens ($). No one wants to work with a dogmatic individual but I’d rather a nit picker than a human or agent slop machine.
Earlier quoted context omitted.
> but harmful to late-stage developers who adopt it as dogma. Even Robert Martin, very often in his videos and blogs, espouses "engineering judgment" and is quite fine abandoning advice in his book when the situation calls for it. If performance is important and clean code is impacting it, he won't object to your breaking the rules. It's mostly with his TDD evangelism that he goes (a little) crazy.
I just think - in the book at least - he has really bad taste. The examples are full of “spooky action at a distance”. He writes the exact sort of class functions that make a lot of OO terrible to work with, where a function that should be pure has some weird hidden side effects. Code like that is really difficult to reason about and impossible to reuse safely. Somewhat ironic, given what he preaches in the rest of t…
Earlier quoted context omitted.
No, it's a false dichotomy. When working on large applications, by far the single most important factor in performance is having simple and understandable code. Understandable but slow code can be fixed. Incomprehensible code can't, so it either stays slow or gets worked around with caching/async processing/etc. If you want fast software, you should write the simplest thing that isn't obviously stupidly slow, then me…
This is only true up to some point of skill & complexity. Hotspot optimisation only takes you so far. Eventually you can end up with a program that is fast everywhere but which is still somehow slow at the macro level. Like LLVM. Truly fast software is made by thinking about data flow from the start. If you use the right data structures, the code takes care of itself. But this is far beyond Clean Code. The examples i…
Clean code like approaches have a very real cost for users (even in languages with good optimizers) and is usually unfixable after the fact.
Earlier quoted context omitted.
I just think - in the book at least - he has really bad taste. The examples are full of “spooky action at a distance”. He writes the exact sort of class functions that make a lot of OO terrible to work with, where a function that should be pure has some weird hidden side effects. Code like that is really difficult to reason about and impossible to reuse safely. Somewhat ironic, given what he preaches in the rest of t…
The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5.…
I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…
> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…
> it's impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It's impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.