Live data from Hacker News

Please do not attempt to simplify this code

github.com

91–100 of 327 posts

Re: Please do not attempt to simplify this code

#91

Why was Space Shuttle code so good and the engineering so bad? The thing was expensive and shit and had a 1.5% catastrophic failure rate for passenger transport. Soyuz was two orders of magnitude better. Russia/USSR have reputation for McGyvering things and US has reputation for gold-plating but US ship is killing people every 65 flights and Russian ship has over 1500 launches without death. Maybe engineers should le…

https://waynehale.wordpress.com/2012/11/12/after-ten-years-a...

> I need to give you the issue from the NASA point of view so you can understand the pressures that they were under. In a developmental program, any developmental program, the program manager essentially has four areas to trade. The first one is money. Obviously, he can go get more money if he falls behind schedule. If he runs into technical difficulties or something goes wrong, he can go ask for more money. The second one is quantity. The third one is performance margin. If you are in trouble with your program, and it isn’t working, you shave the performance. You shave the safety margin. You shave the margins. The fourth one is time. If you are out of money, and you’re running into technical problems, or you need more time to solve a margin problem, you spread the program out, take more time. These are the four things that a program manager has. If you are a program manager for the shuttle, the option of quantity is eliminated. There are only four shuttles. You’re not going to buy any more. What you got is what you got. If money is being held constant, which it is—they’re on a fixed budget, and I’ll get into that later—then if you run into some kind of problem with your program, you can only trade time and margin. If somebody is making you stick to a rigid time schedule, then you’ve only got one thing left, and that’s margin. By margin, I mean either redundancy—making something 1.5 times stronger than it needs to be instead of 1.7 times stronger than it needs to be—or testing it twice instead of five times. That’s what I mean by margin.

> It has always been amazing to me how many members of Congress, officials in the Department of Defense, and program managers in our services forget this little rubric. Any one of them will enforce for one reason or another rigid standard against one or two of those parameters. They’ll either give somebody a fixed budget, or they’ll give somebody a fixed time, and they forget that when they do that, it’s like pushing on a balloon. You push in one place, and it pushes out the other place, and it’s amazing how many smart people forget that.

Re: Please do not attempt to simplify this code

#92
post #59
post #16

> // 1. Every 'if' statement has a matching 'else' (exception: simple error > // checks for a client API call) > // 2. Things that may seem obvious are commented explicitly Honest question: Why invent "safety" practices and ignore every documented software engineering best practice? 2,000 line long modules and 200-line methods with 3-4 if-levels are considered harmful. Comments that say what the code does instead of…

There is no single canonical suite of best practices. There is also nothing harmful or unharmful about the length of a function or the lines of code in a file. Different languages have their opinions on how you should organise your code but none of them can claim to be ‘best practice’. Go as a language doesn’t favour code split across many small files.

> There is no single canonical suite of best practices.

There kind of is, though. Most software engineering books argue for the same things, from the Mythical Man Month to Clean Architecture.

> Different languages have their opinions on how you should organise your code

In general best practices are discussed in a language-agnostic manner.

Re: Please do not attempt to simplify this code

#93

Earlier quoted context omitted.

I'm assuming you mean "non-exception". Apologies if I assume incorrectly. In case I'm correct, this is from Andrew Gerrand, one of the creators of Go: The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled o…

You appear to have misread "expression" as "exception"; this is completely unrelated. An expression-based language is one that lets you do `let blah = if foo then bar else baz`, for example.

I don't think he misread, because I also was puzzled. I had never heard of the term "expression" used in this way, and I imagine I'm not alone. I do greatly appreciate the clarification from you and jtsummers though. I knew of the distinction, but I didn't know of a term for it until today.

Re: Please do not attempt to simplify this code

#94
post #4

// KEEP THE SPACE SHUTTLE FLYING. I understand the intent, but it is a bit funny that the comment references a system that is no longer operational due to its poor safety record. In ten years or so, will people even remember the Space Shuttle in a good light?

Well over 100 successful missions carrying a bunch of people and gear up into outer space and then bringing them back home. I hold it in a good light now, and will likely continue to feel that way. As far as human progress and net good, it was a success.

100 success and 2 failures. About a 1.6% failure rate from memory.

That’s not a great record. Sure it’s a complex field, and it’s not as dangerous as say being US President, but a failure rate of >1% is not something to write home about.

Re: Please do not attempt to simplify this code

#96

Earlier quoted context omitted.

I'm assuming you mean "non-exception". Apologies if I assume incorrectly. In case I'm correct, this is from Andrew Gerrand, one of the creators of Go: The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled o…

You appear to have misread "expression" as "exception"; this is completely unrelated. An expression-based language is one that lets you do `let blah = if foo then bar else baz`, for example.

i honestly struggle with this because its a "i know when i see it" thing, ex. here, const boo = foo ? bar : baz suffices which brings in ~every language I know.

My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value

Re: Please do not attempt to simplify this code

#97
I wrote a toy kubernetes CSI driver recently and found it quite pleasing to do. Bare minimum means implementing just 3 grpc api calls - An informational one and publish/unpublish. Amazon's EFS or EBS CSI drivers are good examples because they're a pretty small codebase. I don't know exactly how this code interacts with the CSI driver itself, but it appears that it is the logic that ultimately results in the volume manipulation calls the controller makes against the CSI driver. It's nice that the complexity is all here, I was actually pretty surprised how simple the drivers themselves are.

Re: Please do not attempt to simplify this code

#98
Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in.

Maybe the disconnect here is that most of my experience is in enterprise software rather than systems software. Perhaps many of the comments in this file seem unnecessary to regular contributors within the k8s project? Whereas if I were writing this same code in an enterprise (and thus expect it to be read by people far in the future lacking context on all the technical details) I would have put -more- comments in this file, given the sheer complexity of all it's doing.

Re: Please do not attempt to simplify this code

#100
post #72

Related article on Space Shuttle Software Quality [0] Excerpt: "But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines lo…

> Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. What exactly do they mean by this? If each of the 3 versions had exactly one bug, isn't this just a weird way of saying the first 2 fixes either didn't work or introduced a new bug?

Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.
Post reply on HN