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

251–260 of 327 posts

Re: Please do not attempt to simplify this code

#251

Post by PeterisP »

ElFitz wrote: post #213
odyssey7 wrote: post #154

Earlier quoted context omitted.

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

That would be the purpose of formal proofs, wouldn’t it? Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms, but this quanta article on a DARPA project showed impressive results [0]. There’s also AWS’ use of TLA+ [1]. [0]: https://www.quantamagazine.org/formal-verification-creates-h... [1]: https://news.ycombinator.com/item?id=22082869

Formal proofs can only prove that the system matches a specification.

Many (most?) non-trivial bugs are actually flaws in the specification, misunderstandings about what exactly you wanted and what real-world consequences arise from what you specified.

Re: Please do not attempt to simplify this code

#252

Post by swiftcoder »

Symbiote wrote: post #235
swiftcoder wrote: post #226

Earlier quoted context omitted.

Not just testing - line-by-line code review of the entire system by a panel of experts. Outside of aerospace/defence/nuclear this style of review is not very common.

I don't know about now, but software verification would also be used in consumer electronics. Fixing a bug in 10,000 washing machine control boards is very expensive when it entails sending a technician to every house to replace the circuit board.

Yeah, I guess for devices that can't receive OTA updates that makes sense. Though I fear that segment of the market is rapidly shrinking - televisions have ubiquitous software update capabilities now, and even washing machines are increasingly internet connected.

We didn't apply anywhere near that kind of quality control to smartphones or VR headsets. Once users are trained to install OTA updates to fix issues, most of the impetus for extreme quality control outside of the bootloader->OTA update path is gone

Re: Please do not attempt to simplify this code

#253

Post by ChrisMarshallNY »

akira2501 wrote: post #143
dpedu wrote: 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?

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

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

This reminds me of the Quality culture, at my last job, which was a famous Japanese optical corporation.

It was deliberately set up, so there was an adversarial relationship between QA, and Development, with QA holding the aces.

As a Development manager, it used to drive me nuts (Ed. Well, it wasn’t much of a “drive.” More like a short putt). It did result in very high-Quality software, but at the cost of agility.

It reflected their hardware development methodology, which regularly resulted in stunningly high-Quality kit, but I think caused a lot of issues with the usability and effectiveness of their software.

Re: Please do not attempt to simplify this code

#254

Post by wouldbecouldbe »

nimih wrote: post #144
wouldbecouldbe wrote: post #3

Earlier quoted context omitted.

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

There are just very few applications that actually need all of this. maybe 1 tot 0.1%, for instance vercel might need it. But 95-99% can just run on several "simple" servers & keep deployment times within minutes and no complicated stuff needed. Yet Kubernetes get's pushed all the time.

Re: Please do not attempt to simplify this code

#255

Post by wouldbecouldbe »

Sohcahtoa82 wrote: post #14
wouldbecouldbe wrote: post #3

Earlier quoted context omitted.

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.

yeah maybe it does, but when you have a hammer everything looks like a nail. Kubernetes is used all the time nowadays on simple projects just because it's the most intellectual pleasing solution. This is creating high maintainance costs by locking in companies with extremely complicated software where it's just not needed.

Re: Please do not attempt to simplify this code

#256

Post by iainmerrick »

drewcoo wrote: post #250
iainmerrick wrote: post #106

Earlier quoted context omitted.

Swift's "guard" statement would be pretty handy here.

if (foo) { bail out } They're known as guard statements regardless of language. https://en.wikipedia.org/wiki/Guard_(computer_science) Swift has a guard keyword, but the construct feels a little awkward given most languages do the above. It makes me do a double take. guard !foo else { bail out }

No, "guard" in Swift is special. Once you're in the "else" block, you MUST return or call a non-returning function (e.g. abort).

It's specifically designed to prevent bugs where flow control accidentally resumes from an error handler.

It's the same idea as the "every 'if' must have an 'else'" guideline in the code being discussed, except with "guard" the compiler will detect violations. It's a good thing.

Re: Please do not attempt to simplify this code

#257

Post by high_na_euv »

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…

> 200-line methods with 3-4 if-levels are considered harmful.

Maybe if you are in love with software evangelists (bullshitters) like Uncle Bob

Re: Please do not attempt to simplify this code

#260

Post by theshrike79 »

matthewmacleod wrote: post #90

Personally I love this level of verbosity in code. There are still way too many levels of nested control flow for my taste—I find that makes it exceptionally hard to retain context—but at least there are early returns.

With a half decent editor you can fold them down so that just the comment on top of the if branch is visible
Post reply on HN