Don't write bugs • Hacker News Board

Re: Don't write bugs

#111

Post by jfrunyon » Wed, Oct 06, 2021, 9:08 PM UTC

horsawlarway wrote: post #104

jfrunyon wrote: post #101

Earlier quoted context omitted.

You absolutely can have a complete mental model of the thing you're coding. Especially if you properly break it down into pieces (modules, libraries, functions, whatever you want to call them) which can be understood as a unit. The biggest problem is that many people use libraries as a crutch, without any knowledge of how they work or what they actually do.

define "complete". Because I bet you fucking money you aren't modeling the actual behavior of any modern x86_64 cpu in your head.

You're not coding any modern x86_64 cpu. Your program might need to work around hardware bugs but those bugs are not things you wrote.

Of course, I also never said x86_64 was a good structure. A bit of reading comprehension might even reveal the implication that simple is better.

Re: Don't write bugs

#112

Post by hcarvalhoalves » Wed, Oct 06, 2021, 10:53 PM UTC

AnimalMuppet wrote: post #109

hcarvalhoalves wrote: post #73

The term "bug" is kind of overloaded at this point. It would be more useful to talk about different classes of software defects: - Incomplete/ambiguous specification - Unhandled IO errors - Unbounded buffers/memory, unhandled OOM errors - Defects introduced by state mutation - Defects introduced by concurrency - Lack of idempotence - Lack of back-pressure - Non-determinism - API changes - Low performance Only some of…

Lack of back pressure? What kind of software defect is that? I've never heard of "back pressure" in a software context.

When a system is unable to serve any more requests it should signal back to the client (“backpressure”) instead of accepting requests unconditionally. Example: DDoS your own system by using unbounded queues. Something like blocking queue + timeout can help avoid it.

Re: Don't write bugs

#113

Post by larrik » Thu, Oct 07, 2021, 1:56 PM UTC

jerf wrote: post #83

larrik wrote: post #82

Earlier quoted context omitted.

> if my API had a different input type for each country's tax ID Like you just add a new field for every country you support? I can imagine quite a few ways to break that. For instance, my system has users from USA and CA, and I just send you everything in the SSN field, because I didn't consider the CA users when I wrote it. The simple way would have just worked, but now the API is broken for me.

No, add a new type. If your SSN is of type "USSocialSecurity" and the canadian system needs "CanadianTaxID" (sorry, I don't know what it is) then the API will not accept the wrong thing in the wrong place. "But what if I label it incorrectly and send it along?" Then that's a bug in your code. No amount of my API design can prevent bugs in your code. All my API can do is not help you write bugs in your code. I can't s…

oh, this is XML land then. Not convinced my point was wrong, though.