Please do not attempt to simplify this code • Hacker News Board

Re: Please do not attempt to simplify this code

#141

Post by DSMan195276 » Tue, Aug 06, 2024, 11:52 PM UTC

mumblemumble wrote: post #115

wavemode wrote: post #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 her…

I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…

I agree to a point, but I would separate explicit code from excessive commenting. Explicit code is good because it lets you explain to the reader what you're actually trying to do. Excessive comments (or even comments in general) is less so because compiler cannot check them for correctness, if someone simply forgets to update a comment or writes it incorrectly then the only thing to potentially catch it is a code review.

Re: Please do not attempt to simplify this code

#142

Post by runevault » Tue, Aug 06, 2024, 11:53 PM UTC

dskrvk wrote: post #137

bhauer wrote: post #119

Earlier quoted context omitted.

Agreed. Explicitness and comments are very useful in understanding the intended functionality and logic, whether or not the code actually implements that intent correctly (an in providing that intent, they can help identify bugs earlier than they would be identified otherwise).

But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.

Note in Rust if you include comments with code that will run as tests but be inline in your main code instead of having to find the relevant test function to confirm functionality.

https://doc.rust-lang.org/rustdoc/write-documentation/docume...

Re: Please do not attempt to simplify this code

#143

Post by akira2501 » Tue, Aug 06, 2024, 11:54 PM UTC

dpedu wrote: post #72

boilerupnc wrote: post #8

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?

Known bug.

The SRR (software readiness review) process happened after development but prior to certification for launch. Most of the bugs were found here and were found to have existed in the code since the beginning of the program.

These were overwhelmingly low severity discrepancy reports.

If I recall correctly, there was a time when they were finding lots of bugs through SRR, so the main development team started their own "continuous review" designed to catch bugs before going to SRR. This made the SRR people angry because they were finding fewer bugs and felt the development team was focusing on competition over bug numbers rather than the code itself.

Re: Please do not attempt to simplify this code

#144

Post by nimih » Tue, Aug 06, 2024, 11:56 PM UTC

wouldbecouldbe wrote: post #3

jftuga wrote: post #2

// ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== // // This controller is intentionally written in a very verbose style. You will // notice: // // 1. Every 'if' statement has a matching 'else' (exception: simple error // checks for a client API ca…

hahaha well Kubernetes is the opposite of a special shuttle that keeps on flying. It crashes all the time, version updates etc. If you want stability go to apache or nginx.

If you think nginx is the right tool for solving problems like container deployment, service discovery, cluster scaling, and secret management, then I suppose it's not surprising that you think Kubernetes "crashes all the time" and that a 1 year rolling support window for software releases is an insurmountable obstacle. Kubernetes has a lot of genuine issues and rough edges, but you're kind of showing your ass when you make comments like this.

Re: Please do not attempt to simplify this code

#145

Post by corytheboyd » Tue, Aug 06, 2024, 11:56 PM UTC

neilv wrote: post #67

BTW, when linking to a file in GitHub like this, you can link to a range of lines of the file, by using the URL fragment identifier, like: #L60-L92 https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...

I (well really, a coworker of mine) just today discovered a JetBrains action “Copy GitHub URL” [sic] that, if you have lines of code selected in the IDE, includes those lines in the copied URL fragment. So so so much better than my old workflow of stopping what I’m doing, going to the file in GitHub, and selecting the lines there to share links to bits of code.

Re: Please do not attempt to simplify this code

#146

Post by bigiain » Tue, Aug 06, 2024, 11:57 PM UTC

emerongi wrote: post #15

boilerupnc wrote: post #8

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…

5000 / 17 ≈ 295. Is it a fair assumption to make that a commercial program of equivalent complexity would take 295x fewer man-hours?

As I skimmed that, the text wrapped at the hyphen in man-hours, and my brain autocompleted it to "295x fewer managers" - and it pretty much rings true...

Re: Please do not attempt to simplify this code

#147

Post by twobitshifter » Wed, Aug 07, 2024, 12:05 AM UTC

renewiltord wrote: post #30

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…

Soyuz doesn’t look like it came from a movie and can’t fly like a plane to touch down on a runway.

Re: Please do not attempt to simplify this code

#148

Post by zdragnar » Wed, Aug 07, 2024, 12:06 AM UTC

wavemode wrote: post #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 her…

The one thing that stood out to me is the rather extensive nesting of if-else.

I know this is go code, but there's multiple places that go five branches deep, at least.

It works but it's a style that takes a lot of effort to grow what's happening IMHO.

Re: Please do not attempt to simplify this code

#149

Post by omoikane » Wed, Aug 07, 2024, 12:12 AM UTC

wavemode wrote: post #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 her…

Most likely, this comment was added in response to a botched attempt to simplify code, to serve as a warning for future maintainers to think twice before making a similar attempt.

The commit that added the warning was "Add note about space-shuttle code style"[1], and the one before that was "Revert controller/volume: simplify sync logic in syncUnboundClaim"[2]

[1] https://github.com/kubernetes/kubernetes/commit/de4d193d45f6...

[2] https://github.com/kubernetes/kubernetes/commit/8a1baa4d64ca...

Re: Please do not attempt to simplify this code

#150

Post by dotnet00 » Wed, Aug 07, 2024, 12:12 AM UTC

rqtwteye wrote: post #89

boilerupnc wrote: post #8

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…

It would be interesting to see the NASA approach compared to how SpaceX does things. Considering that they have done manned missions they seem to have very similar requirements.

It'd depend on what software is under consideration. IIRC the UI in Crew Dragon is using more contemporary stuff, Node.js I think. This is fine because they have redundancy, there's minimal crew control anyway, and there are manual overrides behind a panel below the screens.

They have 3 relatively modern CPUs setup to run the same code and error check each other, such that if one has an issue, there's still redundancy when it's rebooting.

The software controlling critical systems is probably closer to NASA-esque practices.