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

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

51–60 of 327 posts

Re: Please do not attempt to simplify this code

#51

Post by fleischhauf »

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?

without any knowledge of the other processes involved in space shuttle software development, I highly doubt that the correlation is that easy

Re: Please do not attempt to simplify this code

#52

Post by whalesalad »

bpodgursky wrote: post #37
Sohcahtoa82 wrote: post #19

Earlier quoted context omitted.

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

Did the amount of time spent on code formatting incur an opportunity cost for more impactful engineering safety investments?

the issues are pretty well documented and are all human failures.

https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...

the challenger disaster is noteworthy as a tragic incident because many individuals tried to stop the launch knowing this (ahem, hardware) issue was present. to many people, it was not a surprise when it happened.

Re: Please do not attempt to simplify this code

#53

Post by ajford »

bpodgursky wrote: post #37
Sohcahtoa82 wrote: post #19

Earlier quoted context omitted.

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

Did the amount of time spent on code formatting incur an opportunity cost for more impactful engineering safety investments?

Given that the engineering safety folks are more than likely not the ones writing the code, I doubt it.

Re: Please do not attempt to simplify this code

#55

Post by mden »

jsbg wrote: 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…

> Why invent "safety" practices and ignore every documented software engineering best practice?

That seems unnecessarily brutal (and untrue).

> 2,000 line long modules and 200-line methods with 3-4 if-levels are considered harmful

Sometimes, not always. Limiting file size arbitrarily is not "best practice". There are times where keeping the context in one place lowers the cognitive complexity in understanding the logic. If these functions are logically tightly related splitting them out into multiple files will likely make things worse. 2000 lines (a lot of white space and comments) isn't crazy at all for a complicated piece of business logic.

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

I don't think this is a clear cut best practice either. A comment that explains that you set var a to parameter b is useless, but it can have utility if the "what" adds more context, which seems to be the case in this file from skimming it. There's code and there's business logic and comments can act as translation between the two without necessarily being the why.

> Gratuitous use of `nil`

Welcome to golang. `nil` for error values is standard.

Re: Please do not attempt to simplify this code

#56

Post by kuschku »

arwhatever wrote: post #13
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…

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

I used to be skeptical about introducing complex expressions to C-syntax languages for a long time until I saw how well Kotlin handled `when`.

Now every time I use typescript or go I have trouble trying to express what I want to say because `when` and similar expressions are just such a convenient way to think about a problem.

In go that means I usually end up extracting that code into a separate function with a single large `switch` statement with every case containing a `return` statement.

Re: Please do not attempt to simplify this code

#57

Post by tomcam »

jerlam wrote: 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?

Is its poor safety record due to software failures?

Re: Please do not attempt to simplify this code

#58

Post by fleischhauf »

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…

I wonder about spaceX track record

Re: Please do not attempt to simplify this code

#59

Post by ljm »

jsbg wrote: 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.

Re: Please do not attempt to simplify this code

#60

Post by seabass-labrax »

jerlam wrote: 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?

The situation with the Space Shuttle is more complex than simply poor safety. In terms of missions, it has a better record than many other launch vehicles - 2 fatal missions out of 135 for the shuttle, 2 out of 66 for the Soviet-era Soyuz, and a frighteningly poor 1 fatal mission out of only 12 spaceflights for SpaceShipTwo.

However, the Space Shuttle had a much larger crew capacity than most missions probably needed (up to eight astronauts compared to Apollo or Soyuz's three), especially considering that the majority of Soviet/Roscosmos, ESA and CNSA missions were autonomous and completely unmanned - no crew to endanger!

Perhaps that makes the metaphor even better for Kubernetes: an highly engineered, capable and multi-purpose system requiring considerable attention, and probably used a little more than it should be.

Post reply on HN