Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean Code, Horrible Performance” Discussion

github.com

Post reply on HN
Print view View original

181–190 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#181

Post by lazyasciiart »

fwlr wrote: post #59
lazyasciiart wrote: post #51

Earlier quoted context omitted.

> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.

It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.

Of course it detracts from your argument, because your argument is using it as evidence that clean code is not good for performance.

Re: “Clean Code, Horrible Performance” Discussion

#182

Post by lll-o-lll »

osigurdson wrote: post #155
pkolaczk wrote: post #8

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…

I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.

Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre, is of course the reason behind this.

I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.

Re: “Clean Code, Horrible Performance” Discussion

#183

Post by globalreset »

jmartin2683 wrote: post #159

I shudder to even think of the cumulative ecological cost of Bob's line of thinking, here. Imagine if Henry Ford did this... we'd all be getting 0.3mpg, but hey... productivity!

Imagine software that was delivered 6 months earlier but is 2x slower than it could be. This lead to productivity increase of it's users of 2x during that 6 months. At the expense of some extra electricity use worth $100, they made $10M worth of real world productivity.

My point is... the thing that is much worse than software that is unnecessary slow, is the software that was not yet written at all.

Now ... I think some of the Clean Code ideas are meh. But their performance is not the only or even one of most important aspects of it.

Re: “Clean Code, Horrible Performance” Discussion

#184

Post by osigurdson »

lll-o-lll wrote: post #182
osigurdson wrote: post #155

Earlier quoted context omitted.

I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.

Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre , is of course the reason behind this. I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.

>> Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour

This is a great comment. Quotable even.

Re: “Clean Code, Horrible Performance” Discussion

#185

Post by roarcher »

blippage wrote: post #83

The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin. Functions should do only one thing. Sure, but what does that actually /mean/? If a function calls two other functions, then surely, by definition, it's doing two things? So how much a function is doing is a question of how far you stand back when looking at it. Also, if you follow a rule of functions having only 2-4 lines, then y…

> The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin.

Totally agree. I believe "Uncle" is a pretty ingenious piece of branding meant to paint him as an implicitly trustworthy and wise figure that I should feel endeared to. He's just a guy who has built a career out of offering his opinions on how others should do a job he's never done. Notice that his About page [0] doesn't mention a single piece of software that he's actually built.

He reminds me of a company I used to work for. It was a healthcare architecture firm that got sued so many times for their fuckups that they pivoted to being a "thought leader" in their industry. Instead of continuing to build hospitals, they focused on consulting and publishing articles with their innovative [1] ideas about how hospitals should be designed. A classic case of "those who can't do, teach".

[0] http://cleancoder.com/files/about.md

[1] I shit you not, one of their ideas was a "hover gurney" that was basically a giant quadcopter with a bed on it. It was supposed to be easier to move. Blasting germs all over the hallway with hurricane-force winds was apparently not an issue anyone thought worthy of consideration.

Re: “Clean Code, Horrible Performance” Discussion

#186

Post by Gibbon1 »

pkolaczk wrote: post #8

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…

> Clean Code is mostly a premature optimization in code flexibility > in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.

Tying these two together. Clean Code doesn't distinguish between framework code and business logic code. Or more you should write the latter like the former. The problem is writing framework code is hard to do well. It needs to be well thought out, bullet proof, and importantly well documented. That takes a lot of time and effort and running the code under a number of different use cases.

One is better off writing business logic as straight forward and goal directed as possible.

Re: “Clean Code, Horrible Performance” Discussion

#187

Post by taeric »

inimino wrote: post #54
taeric wrote: post #21

Earlier quoted context omitted.

Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.

Since this gets repeated so often, it is probably worth reproducing a little more of Knuth's quote. "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We shoul…

I'd go further and focus on "small efficiencies" part of that. The assumption used to be high that you would stay cognizant of large efficiencies.

In a very real sense, this is like a lot of the rhetoric around Big O analysis. From all that you ever hear online, you would think that Knuth's analysis was focused on only the Big O descriptions of algorithms. Reading the book, however, you find much more detailed takes of individual algorithms. Such that the aim was never to not be able to do the small, but realize that the comparison is dominated by the big.

Such is it with efficiency. The assumption was that you did not pick purposely inefficient methods, at large. And that you can focus on the very small level details where you get the best return on them.

Now, I think "clean code" is getting a bit thrown under here. Picking the specific examples that were easy to talk about in a pedagogical manner is not doing any favors to the general ideas from either side. And I consider myself mostly on the anti side of the "clean code" debate.

Re: “Clean Code, Horrible Performance” Discussion

#188

Post by taeric »

rhdunn wrote: post #66
taeric wrote: post #21

Earlier quoted context omitted.

Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.

That quote isn't saying not to optimize. It's saying not to optimize at the start. When you initially write your code, you won't know where the bottlenecks are. So first choose and write a sensible implementation using appropriate algorithms and data structures to complete the task. Then, when you have something working, measure its performance against real world data, not against synthetic benchmarks. You can use sy…

The quote specifically calls out "small efficiency gains" as a premature optimization. Specific example is a goto statement that is not as "clean" as many other control structures, but still makes a big impact on a particular implementation of a routine in question.

Implicit, I argue, is the idea that you were also not reaching to methods that were adding inefficiencies. That is, I think the argument is fine that you can and should try to write efficient code at a high level.

Re: “Clean Code, Horrible Performance” Discussion

#189

Post by lll-o-lll »

bcrosby95 wrote: post #148
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…

What happens when you have new requirements that weren't envisioned by the original designers, who are no longer there? How do you unravel the design to the point where you can create a new one?

With great effort. That’s kind of my point though. It’s when you are changing the design from the originally understood “these are the ways to extend and add”, to a new paradigm, that you should be expending great effort.

In such a code base, it quickly becomes understood that if changes are required to “framework Doom” in order to achieve a new feature, the time budget will need to be large. It’s built in tech-debt prevention.

Post reply on HN