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

Programmers should never trust anyone, not even themselves

carbon-steel.github.io

Post reply on HN
Print view View original

131–140 of 163 posts

Re: Programmers should never trust anyone, not even themselves

#131

Post by danielmarkbruce »

kryptiskt wrote: post #48

I think "trust, but verify" (as mentioned in the article) is a much more useful motto than "never trust anyone". The latter isn't an useful attitude, if you took it seriously you would have carefully check or rewrite everything from the ground up. And then you'd either have to trust the hardware anyway or enlist in a course on VLSI design. "Trust, but verify" is much more practicable, at least if you don't feel the n…

In some sense you are saying "i can't stand making people uncomfortable so I contort reality".

If you have to verify, you don't trust. Google "trust definition". Here is the first result:

"firm belief in the reliability, truth, ability, or strength of someone or something".

There is no reasonably sized body of code I ever wrote where I'd have a "firm belief" it was error free.

There are many situations where we shouldn't believe someone's work is error free. It's fine. Anyone who has ever worked in a field where it can be shown that some work has an error knows how many errors humans make. Anyone who is honest with themselves in the software business knows just how easy it is to make an error.

If you need a pithy phrase: "Assume good intent and capability, but verify work".

Re: Programmers should never trust anyone, not even themselves

#132

Post by skydhash »

atoav wrote: post #127

As an electronics guy this is really ingrained. Not only could you easily waste days on a problem if you assume things rather than check them, in some cases you might also get a painful experience or depending on what you're working on that mistake might even be your last, burn down a house, kill others or what not. Checking your priors is one thing, ensuring your stuff fails gracefully if they are abnormal another.…

Hardware fails because of physical rules, software is more abstract and more flexible. I agree that higher standards should be required, but business people won't do it as it will make it as slow as hardware engineering. I'd love to see formal verification for at least the business core of any application. That should incentivize product managers to write better specifications.

Re: Programmers should never trust anyone, not even themselves

#133

Post by darby_nine »

bruce511 wrote: post #4

>> Random access of a character in a text buffer could take constant time (for ASCII) or linear time (for UTF-8) depending on the character encoding This is true, but incomplete. All unicode encodings take linear time, not just utf-8. That's because a character can contain multiple code points. Utf-32 allows for random access of code points in constant time, but not characters. Utf-16 has variable length code points…

I've come to the conclusion that "character" is worth abandoning as a coherent concept. Words and bytes are much more useful and easier to define and aren't dependent on which runtime you're using, and the number of times it's worth slicing a word into characters is actually pretty low. One exception to this might be chinese (and I'm sure others) where differentiating words is not a straightforward task of splitting by whitespace, but they also have much more straightforward glyph rendering bypassing most of unicode's nastiness. Random access strings in chinese are actually super straightforward once you abandon run length encoding to heavy users of ascii and emoji.

Re: Programmers should never trust anyone, not even themselves

#134

Post by atrus »

agentultra wrote: post #115

To me, this is the argument for formal verification. I don't want to hear a hand-waving explanation that this algorithm will always complete. If the algorithm is sufficiently complex I want proof. Otherwise, why would I believe you? Abstractions, in the mathematical sense, always hold (unless there is a flaw in the definition itself). Axioms in any sense are always going to throw a wrench in things. Thank Godel. But…

> Abstractions, in the mathematical sense, always hold (unless there is a flaw in the definition itself). Axioms in any sense are always going to throw a wrench in things. Thank Godel. But that shouldn't mean we cannot make progress.

But this seems like an argument against formal verification. Formal verification is 100x harder than writing tests...and still doesn't guarantee correctness? Those axiom wrenches are still there, those flaws in the definition are still there, not to mention the flaws in the proof writing. All that extra effort for what gain?

Re: Programmers should never trust anyone, not even themselves

#135

Post by mbonnet »

agentultra wrote: post #115

To me, this is the argument for formal verification. I don't want to hear a hand-waving explanation that this algorithm will always complete. If the algorithm is sufficiently complex I want proof. Otherwise, why would I believe you? Abstractions, in the mathematical sense, always hold (unless there is a flaw in the definition itself). Axioms in any sense are always going to throw a wrench in things. Thank Godel. But…

Formal verification is nice, but requires crazy skilled people at high cost. It's not always practical/feasible to have as part of your SWE process.

Re: Programmers should never trust anyone, not even themselves

#136

Post by agentultra »

atrus wrote: post #134
agentultra wrote: post #115

To me, this is the argument for formal verification. I don't want to hear a hand-waving explanation that this algorithm will always complete. If the algorithm is sufficiently complex I want proof. Otherwise, why would I believe you? Abstractions, in the mathematical sense, always hold (unless there is a flaw in the definition itself). Axioms in any sense are always going to throw a wrench in things. Thank Godel. But…

> Abstractions, in the mathematical sense, always hold (unless there is a flaw in the definition itself). Axioms in any sense are always going to throw a wrench in things. Thank Godel. But that shouldn't mean we cannot make progress. But this seems like an argument against formal verification. Formal verification is 100x harder than writing tests...and still doesn't guarantee correctness? Those axiom wrenches are sti…

It guarantees correctness vis. the axioms chosen. That's a much more powerful statement and guarantee than a unit test which only exercises a single example.

A formal proof that an algorithm makes progress, doesn't require a lock, or whatever property the proof is arguing is 100% guaranteed for every case.

For example, a simple function over the set of integers. A unit test can only test individual elements of the set. A proof demands more: the property must hold over all elements of the set.

The Incompleteness Theorem puts a limit on the provability. That hasn't stopped mathematicians from pursuing the formalization of mathematics. It shouldn't stop computer scientists and programmers either. In fact it tends to make us more honest about the limits and capabilities of our systems.

Re: Programmers should never trust anyone, not even themselves

#137

Post by fatnoah »

Spivak wrote: post #108
fatnoah wrote: post #95

Earlier quoted context omitted.

> "Trust, but verify" Even though my entire career has been software, I was an Electrical Engineering major, so I have taken VLSI design (and even designed an 8-bit ALU). My first job was writing embedded software, and would frequently "trust, but verify" the hardware through the use of a logic analyzer. When I pulled out printouts from the analyzer to show the hardware team that the hardware had a bug, the surprised…

This is why blameless postmortems are such good thing. Going one step further having a culture where finding a bug or defect in your own code/design is rewarded makes it so people aren't afraid but excited to talk about them.

> This is why blameless postmortems are such good thing.

100%. I'm very much a fan of asking _what_ happened and then figuring out how to prevent it from happening ahead. Look back to inform the future, not to find blame. Ultimately, if 1 person can blow things up, it's a bigger issue at play.

Re: Programmers should never trust anyone, not even themselves

#138

Post by drewcoo »

atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

Tests don't find bugs. They find things a developer needs to investigate.

Most tests I've seen aren't aids to diagnosability, so if there is a bug, the developer is still needed to find it.

> tests are written too early, using a data structure that gets changed in development

I wouldn't call this "too early," but "testing the wrong thing" if they were testing internal particulars instead of behaviors.

Re: Programmers should never trust anyone, not even themselves

#139

Post by drewcoo »

nullserver wrote: post #77
atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

I inherited an ancient project that had literally tens of thousands of test. I reviewed hundreds of them, tried rewriting dozens of them. Eventually, realize that essentially all of the tests were just testing that mock data being manually manipulated by the test gave the result of test expected. Absolutely nothing useful was actually being tested. Some team spent a couple of years writing an unholy number of tests a…

I've never seen that but I've heard the claim before.

So . . . is the team of devs who spent years writing and maintaining those tests incompetent or is it the new dev with the complaint? If it was the whole team, how did that happen?

Re: Programmers should never trust anyone, not even themselves

#140

Post by IshKebab »

globular-toast wrote: post #38
IshKebab wrote: post #18

Earlier quoted context omitted.

I don't think the author was under the impression that banks physically store money. They meant the digital currency does not sit idle on the bank's asset list. They're just using normal human language.

The deposits aren't assets to the bank, they are liabilities. The loans are their assets (your liability is their asset). They don't need to "do anything" with your deposit because it doesn't exist. If I increment the number 2 to the number 4, have I brought something into existence, in particular 2 "things"? What is that? Why can't I just bring 3 things into existence without incrementing the initial number? If this…

> They don't need to "do anything" with your deposit because it doesn't exist.

Uhm yeah they do. If they take my money and then just do nothing with it then they won't make any money from it. Banks invest your money.

(I don't think that's the main way they make money - it's probably mostly from credit card interest, but they definitely do it.)

The money you pay into banks absolutely exists in every sense.

Banks can create money when they issue loans, which I suppose you could argue doesn't exist. But they aren't allowed to create unlimited money. I'd say it exists as much as any other money exists.

Post reply on HN