2. It's not too surprising given the way ntural selection finds efficiencies in quite complex structures. But trying to reason about how they work is tricky. When engineering things, being able to reason about a system is often a lot more important than that system being close to maximally efficient. Main point is, I think you should always be aware of what trade offs are you making.... much like my point #1, if you use this to justify being messy, then it's probablly the wrong tradeoff, but shhh, my partner doesn't read this :)
The Efficiency-Destroying Magic of Tidying Up
91–100 of 196 posts
Re: The Efficiency-Destroying Magic of Tidying Up
#92Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that cr…
Re: The Efficiency-Destroying Magic of Tidying Up
#93Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that cr…
> Im tired of it. Its not effecient. Its bad and you should feel bad.
You're ignoring that sometimes, measurably more efficient code is less readable, possibly much less readable. If this weren't the case, there'd be no such thing as sophisticated data-structures and algorithms.
This doesn't mean anyone should make an uncommented ball of mud with no comments, of course.
> No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way.
The usual wisdom about efficient code, answers this: if you aren't measuring performance, that means you don't really care about performance.
If you're going to great efforts, and writing less readable code, on the hunch that this is more efficient, then sure, you're doing it wrong.
Re: The Efficiency-Destroying Magic of Tidying Up
#94Re: The Efficiency-Destroying Magic of Tidying Up
#95> When computers design things, they look very different. Yes, because the computer assumes they're not going to change. The "tensile structure" looks cool now, but throw it in the back of a truck for 3 months and see if it's still algorithmically perfect. Parts get beat up. Tabs get bent a little. Maybe we'll want to grind off one of those tabs that we're not using because it's in the way, or weld on a new one. With…
There are ways to make such "organic" structures more resillient. Life is one huge proof of that. One of the reason biologists and medical researchers have so much trouble figuring how anything works in living organisms is because in biology, there are very few clear boundaries; every process is mixed up with a lot of other ones. And yet the final result is incredibly resilient.
The house I'm living in has been around 30+ years, but in the last 5 years, I've witnessed several trees in the yard die.
I guess what I'm saying, is there is a trade off between easy to understand and fix (orderly) and resiliency(biological), and even then I see a lot of orderly things outlast the chaotic systems.
Re: The Efficiency-Destroying Magic of Tidying Up
#96Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that cr…
Re: The Efficiency-Destroying Magic of Tidying Up
#97I mean that image of the 'before/after 'topological optimization' seems like a poor analogy. >confirming that our intuitive preference for “straight line” designs has nothing to do with performance As the first is made to be made because of its 'straight lines'. You can see the welds and logic in it, as something easily made. While the second is something only achievable via 3D-Metal printing or possibly very complex…
That's the first thing that struck me as well; a person like my dad (a retired blacksmith), could make the first one ...
Re: The Efficiency-Destroying Magic of Tidying Up
#98this reminds me of that time blowhard Richard Dawkins disected an animal (can't remember which) and proceeded to bang on about how stupid the vagus nerve is, wandering all over the place as it does for no apparent reason. People used to say the same of the appendix and adenoids; that they're pointless vestiges, the blindness of evolution, contingent structures. Dawkins said obviously the nerve should simply connect d…
Re: The Efficiency-Destroying Magic of Tidying Up
#99Earlier quoted context omitted.
There are ways to make such "organic" structures more resillient. Life is one huge proof of that. One of the reason biologists and medical researchers have so much trouble figuring how anything works in living organisms is because in biology, there are very few clear boundaries; every process is mixed up with a lot of other ones. And yet the final result is incredibly resilient.
Sure, but there's some downsides to that. If a part in my car fails, the mechanic pulls it out and bolts in a new one without much consideration for the rest of the system. If a part of my body fails, there's a slim chance I might be able to get a replacement from another person, and I'll have to be on immuno-supressents for life, and very expensive people will be needed to perform the installation, and things often…
Re: The Efficiency-Destroying Magic of Tidying Up
#100Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that cr…
I disagree with such a blanket statement. Interfaces must remain simple, while implementations are free to be as complex as needed. Take a look at this article -- clearly the SIMD code is dense to get through, but it's very-much-so worth it for the performance gains. https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove...