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

151–160 of 163 posts

Re: Programmers should never trust anyone, not even themselves

#151

Post by ZoomZoomZoom »

bitwize wrote: post #106
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…

"Trust, but verify" comes from the Soviet Union and is an example of Russian humor. It helps that the Russian words for "trust" and "verify" rhyme. It really means something like "act like you trust the person, but secretly, don't trust them and double check that they've fulfilled their commitments". Putting on a smiling face and acting as if everybody was acting in good faith, while secretly expecting the stab in th…

Don't know how you come up with so much specific implicit meaning for the phrase. It simply means you can have high expectations but never a 100% guarantee.

It's interesting to note that English wiki has an article about the phrase, but Russian doesn't.

Re: Programmers should never trust anyone, not even themselves

#154

Post by robertlagrant »

dncornholio wrote: post #120
robertlagrant wrote: post #44

Earlier quoted context omitted.

I suppose the question is: why bother with trust? Why not just "verify"?

Well the thing is, that’s how trust already works isn’t it? Trust doesn’t require any effort. Trust means I won’t put in effort. So I just verify, because I trust.

Okay, so why say it? Why not mention breathing and eating as well, given we're already doing them?

In other words: why is it included?

Re: Programmers should never trust anyone, not even themselves

#155

Post by atoav »

skydhash wrote: post #132
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.

The electrical grid is typically 230/120 Volts AC at 50/60 Hz. A bad design will rely on that and fail once something about that is out of whack in either direction. A good design will gracefully shutdown, or operate normally within reasonable thresholds.

You can apply the same principle to programming (in fact, many programmers do). If your program falls completely fall and explode into pieces once any peripheral, call, timing, or whatever isn't as expected, then it isn't a resilient program. If it fails in unexpected ways while still writing data you might even have a dangerous program.

So many programmers are happy with writing a program that works. That would be as if a car manufacturer would be happy to call it a day if the car manages to accelerate.

Re: Programmers should never trust anyone, not even themselves

#156

Post by JohnFen »

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…

I think "trust but verify" is logically identical to "don't trust", to be honest.

But trust isn't a binary, all-or-nothing sort of thing. There are always degrees. "Trust but verify" makes that explicit.

Re: Programmers should never trust anyone, not even themselves

#158

Post by kubanczyk »

randomdata wrote: post #86
gchamonlive wrote: post #79

Earlier quoted context omitted.

Tests are akin to scientific experiments. They test hypothesis and try to falsify claims. They shouldn't be seen as ground truth, but ways to gain information about what the system claims to be doing. In this sense it makes sense that tests will become obsolete or evolve with the system, because the model and domain upon which the system is based also evolves and changes with time.

This is why I'm not sure more languages don't instil the idea of "public" and "private" tests like Go does. Your "public" tests should document the API for future programmers. This is the concrete contract that should never change, no matter what happens to the implementation. If these tests break, you've done something wrong. Your "private" tests are experiments that future programmers know can be removed if they no…

So, test the compatibility guarantee (of your major number in semver).

How is this formalized in Go?

Re: Programmers should never trust anyone, not even themselves

#159

Post by throwaway2037 »

bluGill wrote: post #99
mjevans wrote: post #20

Earlier quoted context omitted.

IMO within a small range iterating isn't too painful. It's probably safe, maybe even close enough to optimal for typical use, to have an array or list of bytestrings for each line. Or maybe more complex Line (of text) objects that record the byte-length, 'codepoint'-length, and '(display)character'-length. There might even be special cases built in for typical and massive documents (number of lines) and overly long l…

In most real world cases N is small and so a linear search for data beats a binary search - the binary search is going to stall the pipeline with cache misses all the time, while the linear search will prefetch everything into the cache before you need it thus resulting in not pipeline stalls. Of course different computers (CPU, memory configuration... they all matter) have different characteristics so where N is lar…

I have heard this a few times now. Honestly, I could not believe it the first time I read it. It is a little bit like 10 years ago, when I finally gave up on using linked lists and just replaced them with dynamic arrays (whatever language is fine) after realising that the memory locality gains (less cache misses) far outweighed the relatively rare instances that I needed to insert/delete from the collection. And, if the collection was small enough, the insert or delete from a dynamic array can be faster than a linked list ... thanks again to memory locality! (Again, my mind was blown by these discoveries.) To be clear to readers: I'm talking about bog-standard CRUD apps written at mega-corps. No special operating environments.

I tried to Google for some blog posts, but I could find anything. Does anyone know of any (amateur) research on this topic? Example: Running on Linux, written in C, what is the threshold for N to switch from binary search to linear search?

EDIT: Fix typos

Re: Programmers should never trust anyone, not even themselves

#160

Post by throwaway2037 »

bloopernova wrote: post #111
dartos wrote: post #64

Earlier quoted context omitted.

I’ve been preaching this for a while. When a codebase gets too big, and devs gets too clever with their tests, the whole test suite becomes complicated. If your test suite is approaching the complexity of the actual codebase (what with layers of mocks and fixtures that are subtly interdependent,) how could you be expected to trust a test you wrote more than the code you wrote.

I (sysadmin/devops) am writing some nodejs and the complexity of the tests is confusing to me. I'm a nodejs beginner to be sure, and I'm not experienced enough to verify what copilot gives me. All those mocks, and other Jest code, all seem overly complicated but I don't know of anything "better".

Don't be ashamed of this. I am a veteran of automated testing (writing automated unit tests for 10+ years). I am constantly disappointed in myself how bloody complicated it is to test some "simple code". And, then I go back and look at old unit tests from a few months ago: "Who wrote this shit!? Oh, me."
Post reply on HN