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

The Efficiency-Destroying Magic of Tidying Up

florentcrivello.com

Post reply on HN
Print view View original

61–70 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#61

Post by geitir »

TeMPOraL wrote: post #49
ken wrote: post #36

> 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.

Through a process where things that are suboptimal die and change happens over tens of thousands of years

Re: The Efficiency-Destroying Magic of Tidying Up

#62

Post by vkou »

afpx wrote: post #56
dionian wrote: post #54

Earlier quoted context omitted.

Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.

It does if it’s a requirement for keeping employees from quitting.

I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists.

I can, however, imagine quitting if my manager is a shitty person.

People don't quit work - they quit managers.

Re: The Efficiency-Destroying Magic of Tidying Up

#63

Post by nickysielicki »

I wrote the following:

> Symmetry underlies almost everything in mathematics and nature.

> It's much more reasonable to assume that our computer programs are not yet good enough to recover that symmetry, than to take the output of current programs as some sort of evidence that asymmetry itself is some sort of ideal.

And then I looked out my window at a tree without leaves, between two buildings, and I'm looking at how unorganized the branches look, and I'm not so sure anymore. It's like the "spherical chickens" joke.

(Sidenote: it's incredible how angry and volatile this comment section is --- my original comment included. Seems this subject can really strike a personal nerve in many of us. Why?!)

Re: The Efficiency-Destroying Magic of Tidying Up

#64

Post by wpietri »

TeMPOraL wrote: post #57
pizzaparty2 wrote: post #53

Sorry 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…

When applying this article to code, I don't think it has anything to do with spaghetti being good. It could be viewed instead as an argument against "architecture astronautics", the "15 layers of abstraction to print 'hello world'" school of software design.

Exactly. I remember being called into consult on an accounting system for microfinance; the target audience was small to medium-sized. The code had an absurd amount of layering; one path I traced copied the data 8 times from fetch to render, each time into a different set of objects that had basically the same fields, but that were conceptually different.

When I asked about this, I was told it was "best practice" and that if they ever needed to scale, there were now many places they could separate things. I pointed out that for the target audience, they probably wouldn't need to scale. But that if they did, it would be because they were doing 7x the work necessary.

The code was certainly "tidy" from the perspective of the guy who got paid a lot of money to produce architecture diagrams. But it was a nightmare from the perspective of an individual programmer trying to add a feature. They would have been way better off without a lot of quasi-religious design theory slowing them down.

Re: The Efficiency-Destroying Magic of Tidying Up

#65

Post by Ensorceled »

dugditches wrote: post #28

I 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

#66

Post by matthewaveryusa »

pizzaparty2 wrote: post #53

Sorry 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...

Re: The Efficiency-Destroying Magic of Tidying Up

#67

Post by mtts »

Uhuhreally wrote: post #16

this 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…

He said it would have been stupid had someone designed it that way but given that it evolved it made perfect sense why it was the way it was.

Re: The Efficiency-Destroying Magic of Tidying Up

#68

Post by soup10 »

pizzaparty2 wrote: post #58
dionian wrote: post #54

Earlier quoted context omitted.

Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.

I agree, beautiful code is often the other extreme. Plus it's often only beautiful to the person that wrote it.

Code that is easy to work with is usually that way because the author went out of their way to make it easy to work with, often this takes 2-3x as long to write as normal code that just works. Publicly exposed api's typically get this special attention and internal things get the normal spaghetti treatment.

Re: The Efficiency-Destroying Magic of Tidying Up

#70

Post by wpietri »

vkou wrote: post #62
afpx wrote: post #56

Earlier quoted context omitted.

It does if it’s a requirement for keeping employees from quitting.

I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.

I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low.

But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.

Post reply on HN