Live data from Hacker News

Please do not attempt to simplify this code

github.com

151–160 of 327 posts

Re: Please do not attempt to simplify this code

#151

Earlier quoted context omitted.

It’s actually so painful to go back to languages without destructuring and pattern matching.

As someone who writes a fair bit of c# making switch and if's into expressions and adding Discriminated Unions (which they are actually working on) are my biggest "please give me this." Plus side I dabble in f# which is so much more expressive.

[dead]

Re: Please do not attempt to simplify this code

#152
post #137
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.

tests -> verify intended functionality implementation (the how is right).

comments -> why intended functionality was implemented that specific way (marketing wanted X because of Y, so we had to do it like Z with a bit of A).

> But comments go out of date

Just like updating the tests when code is changed, update the comment when the code is changed.

Re: Please do not attempt to simplify this code

#153
post #72

Earlier quoted context omitted.

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

[deleted]

Re: Please do not attempt to simplify this code

#154
post #72

Earlier quoted context omitted.

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

“Program testing can be used to create 1 the presence of bugs, but never to show their absence”

1) edited

Re: Please do not attempt to simplify this code

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

Is there any evidence that these things are harmful or just vibes?

Re: Please do not attempt to simplify this code

#156

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…

Where are you getting 1500 Soyuz flights? As far as I can find the number is more like 150. It also experienced failure and loss of crew on two missions (Soyuz 1, Soyuz 11).

Re: Please do not attempt to simplify this code

#157

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…

[deleted]

Re: Please do not attempt to simplify this code

#158
post #156

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…

Where are you getting 1500 Soyuz flights? As far as I can find the number is more like 150. It also experienced failure and loss of crew on two missions (Soyuz 1, Soyuz 11).

It's correct. I have confused Soyuz launcher with Soyuz spacecraft like newbie. It's true. Soyuz spacecraft has early failures (till 1971, none after). Shuttle has late failures (2003, then project decommission). I suppose design improvement in Soyuz, engineering quality decrease in Shuttle. Incompetent early Soyuz design team. Incompetent late Shuttle engineering team. Lack of ethics to make such broken devices.

Re: Please do not attempt to simplify this code

#159

Discussion from 2018: https://news.ycombinator.com/item?id=18772873

wtf I submitted this in 2018?????

good thing thing you wrote a comment here so you can remember what you were thinking next time you read it :)

Re: Please do not attempt to simplify this code

#160

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…

In particular, the every if has a matching else comment doesn't seem reliably true. Many of the unmatched ifs are just simple if (err != nil) { checks, but or other early returns, but outside of those, there do seem to be unmatched ifs.

That said, my experience in enterprise software isn't that extra comments are necessarily present (there was a plague of "// end if" comments in the codebase, but actual descriptive comments were rare).

Post reply on HN