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

221–230 of 327 posts

Re: Please do not attempt to simplify this code

#221

Post by mook »

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.

Outdated comments are great, because it means you probably have a bug right there. If the comment didn't get updated, the code change probably didn't look at all the context and missed things.

Pretty sure I'm guilty of that pretty often.

Re: Please do not attempt to simplify this code

#222

Post by mgsouth »

adrianN wrote: post #189
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 is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.

Let's say you've tested this thing 1 million times. Each time the output was automatically checked by five different and independently-developed test suites. You're ready to swear there's no possible way for it to fail.

And then someone tries it with a ulimit of 16kB.

Does it run?

Do you _know_?

Do you even know what is correct behavior in this situation?

Re: Please do not attempt to simplify this code

#223

Post by spc476 »

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

"Beware of bugs in the above code; I have only proved it correct, not tried it." ---Donald Knuth

Re: Please do not attempt to simplify this code

#224

Post by rob74 »

runevault wrote: post #142
dskrvk wrote: post #137

Earlier quoted context omitted.

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

Go has something similar: functions marked as examples that are both run as tests and shown and run as examples in the documentation (https://go.dev/blog/examples)

Re: Please do not attempt to simplify this code

#225

Post by mckn1ght »

Buttons840 wrote: post #217
mumblemumble wrote: post #115

Earlier quoted context omitted.

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…

The first developer I ever worked with was very explicit, and I learned some important lessons from him. He had created a system in PHP that controlled printers and it was very explicit. He didn't know what a function was, his code had no functions. It was a 5000 line script that would run on a Windows timer, top to bottom. In some places the control structures were nested 17 deep, I counted; an if-statement inside a…

I’m not sure brevity and explicitness are totally orthogonal, explicit sort of implies spelling things out in a longer way. That doesn’t mean that something that is long is thorough, however.

I like the tradeoff the Swiftlang project talks much about: brevity vs clarity (because explicit doesn’t necessarily mean clear, either, as your example shows). I think those are more orthogonal concerns, both important to think about, for different reasons that may often compete.

Re: Please do not attempt to simplify this code

#226

Post by swiftcoder »

daemonologist wrote: post #88
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?

Or maybe between one version and the next they only found one bug (there may have been bugs in the first version which weren't fixed until the third or later) - this seems more plausible to me since it's... rather difficult to count bugs until after you know about them. Of course now the greatness of the feat depends on how much testing there was between versions, but given that it was the shuttle there was probably…

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.

Re: Please do not attempt to simplify this code

#227

Post by asynchronous »

Onavo wrote: post #210
dotnet00 wrote: post #150

Earlier quoted context omitted.

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

Yeah them running a electron style browser in a box GUI was quite a shocker given how much HN bashed electron when it came out.

Can’t hate it if it’s working. They make cool stuff and haven’t had a Challenger incident yet, I wish them the best.

Re: Please do not attempt to simplify this code

#228

Post by swiftcoder »

Onavo wrote: post #210
dotnet00 wrote: post #150

Earlier quoted context omitted.

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

Yeah them running a electron style browser in a box GUI was quite a shocker given how much HN bashed electron when it came out.

Electron was "bashed" for the resource overhead on consumer PCs. That's not really relevant to an aerospace firm who can spec their hardware to match the exact resource requirements of their tech stack.

Re: Please do not attempt to simplify this code

#229

Post by swiftcoder »

burkaman wrote: post #62
emerongi wrote: post #15

Earlier quoted context omitted.

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

No, I don't think so, 295x is a crazy high factor. The article says 260 people are involved, and let's generously say it took 20 years to write the software (the first mission was 10 years after the program started and it was around for a total of 40 years). Dividing by 295 means a commercial team of the same size could have done it in less than a month. Or with a 10x smaller team, about 8 months. I don't think eithe…

We're well in mythical-man-month territory as you try and accelerate the timeline, though. Typical software companies can't coordinate a 260 person team quickly enough to even start a project of that size in a month.

Re: Please do not attempt to simplify this code

#230

Post by runevault »

rob74 wrote: post #224
runevault wrote: post #142

Earlier quoted context omitted.

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

Go has something similar: functions marked as examples that are both run as tests and shown and run as examples in the documentation ( https://go.dev/blog/examples )

Interesting. I don't know when that was implemented in Rust but clearly Go has had it for a long time, since that post is dated 2015.

While things like syntax are important, languages adding tooling like this (along with stuff like package managers) is so important to the continued evolution of the craft of software development.

Post reply on HN