“Clean Code, Horrible Performance” Discussion • Hacker News Board

Re: “Clean Code, Horrible Performance” Discussion

#171

Post by badpun » Sat, Mar 11, 2023, 5:15 PM UTC

jenadine wrote: post #60

userbinator wrote: post #27

Earlier quoted context omitted.

So many times I've seen a more readable, simpler code turned out to be more efficient as well. In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around. The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appe…

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it…

> Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like.

CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly).

Function calls are slightly more involved, but basically also very, very low level.

Re: “Clean Code, Horrible Performance” Discussion

#172

Post by ajmurmann » Sat, Mar 11, 2023, 5:28 PM UTC

nayuki wrote: post #9

At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem. As an addendum to Casey's video, anoth…

I think Clean Code is more about the ability to easily change the code as requirements change. Readability is one factor, but many of the rules really are only about ease of change. Open/closed and dependency inversion are prime examples of guidelines that are all about ease of change.

Re: “Clean Code, Horrible Performance” Discussion

#173

Post by jskulski » Sat, Mar 11, 2023, 6:14 PM UTC

Manjuuu wrote: post #65

I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind: What have they ever built? Reading code from popular opensource projects…

> What have they ever built?

While I agree that reading code and learning is essential, I don’t think this line of criticism is fair.

I mean like most programmers I’d imagine their years and years of industry work isn’t public. I mean what have I ever built?

Fowler was CTO of ThoughWorks for years and afaik they do really good and deep work, their content is quality. Bob Martin had a similar track record with 8th light, and as an organization is interesting.

That said, I think lumping them together is misguided. I’ve read a lot of both. To me unky bob is can be a divisive gatekeeper who wants to be right, while mFowler is boon to the industry, literally writing the book on refactoring. He has well reasoned and measured arguments.

I mean I think while formulating your own voice is important and essential, it’s also essential to learn from others and pass down knowledge. For some reason, I think our industry sees it as a threat.

Unky bob is a divisive gatekeeper who I suppose did years of industry work? I guess?

To lump Fowler in with unky bob, I just don’t see it.

I mean Fowler I think t started thoughtworks.

Re: “Clean Code, Horrible Performance” Discussion

#174

Post by jdlshore » Sat, Mar 11, 2023, 6:40 PM UTC

pkolaczk wrote: post #86

tpoacher wrote: post #84

Earlier quoted context omitted.

Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed. So you're actually a clean code proponent. As is usually the case with such debates, it is a debate of differing…

Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.

Polymorphism is useful when switch statements are repeated, as a way of eliminating that duplication, not when there’s a single well-encapsulated switch statement.

Re: “Clean Code, Horrible Performance” Discussion

#175

Post by metaltyphoon » Sat, Mar 11, 2023, 6:47 PM UTC

augustk wrote: post #68

readlikeasloth wrote: post #32

Earlier quoted context omitted.

This begs the question: what do you recommend instead?

"Code Complete" by Steve McConnell and "A Philosopy of Software Design" by John Ousterhout.

> "A Philosopy of Software Design"

What a great book. I second this and add my own "The Pragmatic Programmer: 20th anniversary edition"

Re: “Clean Code, Horrible Performance” Discussion

#176

Post by tempaccount420 » Sat, Mar 11, 2023, 7:26 PM UTC

This is too polite... They're trying very hard not to offend each other. Don't base your opinion on the topic from this conversation, I think it's better to hear what each of them have to say "behind their backs".

Re: “Clean Code, Horrible Performance” Discussion

#177

Post by jenadine » Sat, Mar 11, 2023, 8:24 PM UTC

badpun wrote: post #171

jenadine wrote: post #60

Earlier quoted context omitted.

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it…

> Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over a…

you don't write

   if (!condition) 
       goto else_;
   // some code
   goto endif;
   else_:
   // the else block
   endif:
   // More code

Same for loop. That's what we mean by "goto considered harmful".

Re: “Clean Code, Horrible Performance” Discussion

#178

Post by LaLaLand122 » Sat, Mar 11, 2023, 8:25 PM UTC

Aperocky wrote: post #37

Simple > Complex. Every extra year I spend in engineering, it's becoming clear that this is actually one of the only few things that mattered in the long run. I would say this is one of the best if not the best advice in programming and even in life. If clean code doesn't follow that, ditch.

What you say makes a lot of sense.

Now, to give a concrete example. There was a C++ PR introducing an interface taking an argument of type int representing a duration. I suggested using std::chrono::duration (https://en.cppreference.com/w/cpp/chrono/duration), and I was overruled on the basis that "an int is simpler". To have context if you are not too familiar with C++:

- std::chrono::duration is part of the C++ standard library

- It's a wrapper on top of an arithmetic type just giving it "duration" meaning. It's of the same size as the wrapped arithmetic type.

- Yes, you can argue it's more complex since it adds a bunch of templated code on top of a language built-in type.

I'm going to guess that's not what you had in mind with your "Simple > Complex" advise. If so, that's what happens with any advice, even with simple one liners: somebody will take it to justify some crazy decision.

Re: “Clean Code, Horrible Performance” Discussion

#179

Post by jonbronson » Sat, Mar 11, 2023, 8:27 PM UTC

QuadmasterXLII wrote: post #144

lll-o-lll wrote: post #106

Earlier quoted context omitted.

This is why I think the most powerful abstraction for framework with extension points is c++ template meta programming. Wait! Hear me out! Template meta programming is an entirely separate, incredibly complex, programming language distinct from c++. The only people I have ever seen use it in production are exceptionally skilled programmers. Everyone else flees and cowers. If they try to change it it will not compile…

The ITK experience

you just sent shivers down my spine

Re: “Clean Code, Horrible Performance” Discussion

#180

Post by amptorn » Sat, Mar 11, 2023, 8:32 PM UTC

regularfry wrote: post #105

wirrbel wrote: post #31

Earlier quoted context omitted.

Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…

I am not fond of Clean Code, but I am fond of Clean Architecture. It's a much smaller set of ideas, for a start.

I gave up on Clean Architecture after about one chapter. There's a section where he's graphing the number of lines of code in a hypothetical company's codebase over time - it grows rapidly at first and then it levels off, and he points at this like it means anything, specifically like it's a bad thing and it means the software has become difficult to work in. Also this isn't a line chart, it's a bar chart, and the X axis isn't time, it's unlabeled - eventually, in the text, you find that there's one bar per major release of the software, if that tells you anything about how retro this conception of software development is. Another bar chart shows the number of developers growing rapidly, as if that means anything either... It was just baffling.