Live data from Hacker News

Please do not attempt to simplify this code

github.com

11–20 of 327 posts

Re: Please do not attempt to simplify this code

#11
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?

Wasn't a poor safety record whut killed the shuttle. It was the cost, and anticipation of degraded safety, in the future. Even though more astronauts died, because of the two shuttle accidents, than any other NASA disaster, the safety record was absolutely amazing, when we consider everything that was going on. The code seems damn good code.

2/100 catastrophic failures (deaths of entire crew) is not a good record even by the standards of spaceflight.

Re: Please do not attempt to simplify this code

#13
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…

When I looked into Go I found it a bit surprising that someone had created a non-expression-based language as late as ~2009.

I have not familiarized myself with the arguments against expression-based design but as a naive individual contributor/end-user-of-languages, expressions seem like one of the few software engineering decisions that doesn't actually "depend," but rather, designing languages around expressions seems to be unequivocally superior.

Re: Please do not attempt to simplify this code

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

This comment is a complete non-sequitor. Kubernetes solves an entirely different problem from Apache and nginx.

Re: Please do not attempt to simplify this code

#15

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?

Re: Please do not attempt to simplify this code

#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 specifying why are similarly not useful and likely to go out of date with the actual code. Gratuitous use of `nil`. These are just surface-level observations without getting into coupling, SRP, etc.

Re: Please do not attempt to simplify this code

#17
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 is frankly not that impressive for software. A 2-9 system will sometimes work 100x in a row, and a 3-9 system usually will.

Re: Please do not attempt to simplify this code

#18
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?

This code is keeping the space shuttle flying in our memories. Kubernetes never kept the space shuttles flying in a literal way.

Re: Please do not attempt to simplify this code

#19

Earlier quoted context omitted.

Wasn't a poor safety record whut killed the shuttle. It was the cost, and anticipation of degraded safety, in the future. Even though more astronauts died, because of the two shuttle accidents, than any other NASA disaster, the safety record was absolutely amazing, when we consider everything that was going on. The code seems damn good code.

2/100 catastrophic failures (deaths of entire crew) is not a good record even by the standards of spaceflight.

For what it's worth, were any of those catastrophic failures caused by bad code?
Post reply on HN