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

201–210 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#201

Post by peterfirefly »

fwlr wrote: post #117
lozenge wrote: post #111

Earlier quoted context omitted.

There is a lot of inherent complexity there though. Inherently VS needs to support multiple debugging engines and multiple transports to communicate with the debuggee as well (remote vs local debugging). That's OK, two layers of dynamic dispatch is still fast in this context. Do we update call stack and locals window at the same time, or do we update each one as early as possible but show inconsistent data? Do we fet…

>What’s an example of a fast debugger? My apologies in advance if this feels like a gotcha, but… Casey ended up swapping to RemedyBG for debugging. He made a video about why. From about 0:50 onwards he talks about the speed and feature set of the watch window https://m.youtube.com/watch?v=r9eQth4Q5jg Also, I don’t mean to be rude by ignoring all the questions you posed; they’re good questions, I just don’t have answe…

> Casey ended up swapping to RemedyBG for debugging.

Thank you! I had no idea it existed.

The watch window in VS is slower on my 2GHZ laptop than the one in Turbo Debugger was on a 10MHz 8086. That simply makes no sense. I know that the compilers do more optimization and that the debugging info therefore has to be more complex today. It still makes no sense!

Re: “Clean Code, Horrible Performance” Discussion

#202

Post by Manjuuu »

Defletter wrote: post #145
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? You have to be careful with that though. We've had a few people who'd "channel Torvalds", so to speak, by parroting his opinions with abrasive fervour. Any dissenters were treated as either thinking they knew better than him, or being ignorant of his work, or not having an appropriate appreciation for his work. And since Torvalds is very opinionated, so were they. It wasn’t exactly a fun…

I agree with everything you said, especially with how important the role of the maintainer is to get something that keeps working over time (both are builders). And yes, holding someone else opinions strongly doesn't make you instantly a clone of Torvalds, thing that in workplaces with n>1 employees might not be desirable.

Re: “Clean Code, Horrible Performance” Discussion

#203

Post by Manjuuu »

jskulski wrote: post #173
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 lig…

> I mean what have I ever built?

Most of my work is not public too, it doesn't have to be.

> I mean Fowler I think t started thoughtworks.

Yeah, I've been too harsh comparing the two, but as someone that have to fight daily with the consequences of the popularization/normalization/blind adoption of the microservices (his contribution was huge in this field) architecture I'm not sure anymore if his contribution is a net positive. The book on refactoring was great though, product of a different era.

Re: “Clean Code, Horrible Performance” Discussion

#204

Post by goto11 »

pkolaczk wrote: post #114
laserlight wrote: post #102

Earlier quoted context omitted.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

Surprise: I don't use classes. Rust doesn't have them. :P

I use multiple languages and I always consider the context of programming advice. I recommend a broadened perspective.

In general I would rather maintain code by someone who have read Clean Code than by someone who considers it beneath them because they are too elite.

Re: “Clean Code, Horrible Performance” Discussion

#205

Post by lazyasciiart »

fwlr wrote: post #194
lazyasciiart wrote: post #181

Earlier quoted context omitted.

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

No, Casey’s argument is that clean code is not good for performance. The counter-argument to Casey’s argument is that when performance matters, don’t write clean. My counter-counter-argument to the counter-argument to Casey’s argument is that performance is clearly missing even when it matters, so clearly developers aren’t able to figure out when performance matters, so the counter-argument won’t work. Bob is saying:…

So you are saying not that “here they chose Clean Code” but “here they chose not to make good performance”. You’re arguing that the only reason for poor performance is that the developers didn’t think it mattered?

Re: “Clean Code, Horrible Performance” Discussion

#206

Post by fwlr »

lazyasciiart wrote: post #205
fwlr wrote: post #194

Earlier quoted context omitted.

No, Casey’s argument is that clean code is not good for performance. The counter-argument to Casey’s argument is that when performance matters, don’t write clean. My counter-counter-argument to the counter-argument to Casey’s argument is that performance is clearly missing even when it matters, so clearly developers aren’t able to figure out when performance matters, so the counter-argument won’t work. Bob is saying:…

So you are saying not that “here they chose Clean Code” but “here they chose not to make good performance”. You’re arguing that the only reason for poor performance is that the developers didn’t think it mattered?

Sort of? I completely agree with Casey’s argument that Clean Code makes for poor performance, but I’m not making that argument here, he’s made it for me. I am arguing that many developers are really bad at knowing when performance matters, so if they implement the advice of “write clean code, except when performance matters” they are never going to think performance matters and always write clean code. Does that help?

Re: “Clean Code, Horrible Performance” Discussion

#207

Post by bart_spoon »

hdhrufjdi wrote: post #199
bart_spoon wrote: post #192

Earlier quoted context omitted.

How are structs in Rust any different than classes?

Behavior and data is more separated A struct only contains data, however you e.g. can define methods on it or implement traits for it No inheritance.

They don’t only contain data though, you can define methods as you said. Yes, there is no-inheritance, but they contain data, maintain state, and allow for defined methods. 90% of the time people are talking about classes, they are talking about that.

Re: “Clean Code, Horrible Performance” Discussion

#208

Post by darepublic »

Spivak wrote: post #198
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…

This is pretty much my soapbox about DRY. Code is like clay, once it dries it’s not malleable anymore. Components that copy/paste but in doing so are self-contained can be fearlessly changed. And above a certain size dry works against you because when making changes to component A that requires a slight modification of the behavior or component Q deep in the call stack is so painful because the blast radius is huge.…

Having worked with very non dry code where each instance has slight variations but none of the commonalities are captured.. I have to say it can cause a lot of bugs and a lot of headache to maintain.

Re: “Clean Code, Horrible Performance” Discussion

#209

Post by fwlr »

peterfirefly wrote: post #201
fwlr wrote: post #117

Earlier quoted context omitted.

>What’s an example of a fast debugger? My apologies in advance if this feels like a gotcha, but… Casey ended up swapping to RemedyBG for debugging. He made a video about why. From about 0:50 onwards he talks about the speed and feature set of the watch window https://m.youtube.com/watch?v=r9eQth4Q5jg Also, I don’t mean to be rude by ignoring all the questions you posed; they’re good questions, I just don’t have answe…

> Casey ended up swapping to RemedyBG for debugging. Thank you! I had no idea it existed. The watch window in VS is slower on my 2GHZ laptop than the one in Turbo Debugger was on a 10MHz 8086. That simply makes no sense. I know that the compilers do more optimization and that the debugging info therefore has to be more complex today. It still makes no sense!

Don’t get me started. I know I’m sounding like an incurable fanboy for Casey because I mention him in every comment, but it’s only because I am an incurable fanboy for him, his polemics about software being thousands of times slower than it should be these days strike a deep chord with me.

In one of his rants he goes to the effort of booting up a version of Visual Studio from 20 years ago, on a 20 year old machine, to demonstrate that it really truly was way faster back then than it is now: https://youtu.be/GC-0tCy4P1U at 36 minutes in.

Re: “Clean Code, Horrible Performance” Discussion

#210

Post by peterfirefly »

fwlr wrote: post #209
peterfirefly wrote: post #201

Earlier quoted context omitted.

> Casey ended up swapping to RemedyBG for debugging. Thank you! I had no idea it existed. The watch window in VS is slower on my 2GHZ laptop than the one in Turbo Debugger was on a 10MHz 8086. That simply makes no sense. I know that the compilers do more optimization and that the debugging info therefore has to be more complex today. It still makes no sense!

Don’t get me started. I know I’m sounding like an incurable fanboy for Casey because I mention him in every comment, but it’s only because I am an incurable fanboy for him, his polemics about software being thousands of times slower than it should be these days strike a deep chord with me. In one of his rants he goes to the effort of booting up a version of Visual Studio from 20 years ago, on a 20 year old machine ,…

> https://youtu.be/GC-0tCy4P1U

That was a beautiful rant :)

Post reply on HN