Lol genius. Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident. Other times you write some crap code and it has several immediately found bugs but weirdly you emotionally feel more confident in that code because you “fixed” the bugs.
I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that.
Turns out I wasn't running the new version of the function.
I once progressively commented out more and more of a file, trying to find the bit with a bug, until the whole thing was commented out and no source was being compiled yet the original buggy behavior was still there and only THEN did I figure out I was editing a different file than I was compiling.
Echoes of this original sin have shown up repeatedly throughout my life, to be point where it's one of the first things I check when my corrective measure has no effect on problematic behavior.
> Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman
Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.
[1] https://github.com/scottlamb/moonfire-nvr/issues/209#issueco...
(Next was something to snapshot the VM, followed by "apt-get install ext4magic". It worked!)
This used to happen to me all the time too. The solution I ended up going with was to standardize all my build scripts on `./build run` as the way to (build and) run the program, with the actual binary getting shoved in ./bin/ or something to discourage running it directly (which also reduces clutter). Basically, get rid of the "run without building" command entirely.
> I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that.
Either way, it’s just confirmation bias.
Ever since I started adopting TDD, FP-style and using "Railway oriented programming", and always running static-analyzers as part of the build process far more often-than-not my code not only works correctly on first-run, but stopped getting bug reports. It felt weird at first but now it's weird to see my code not work on the first run.
Poisson d'avril!
Of course the second part is ridiculous: unless we are talking about a system formally proven to be bug free, which has enormous limitations, there always will be bugs.
Of course there was the one time when it was an actual compiler bug, heh. https://github.com/rust-lang/rust/issues/51117
* Harmless
* Technically correct
* Hypothetically I guess it might be useful to have a specific rule related to something obvious if you are arguing with a real super-pedant.
https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
There are some other great ones like "TCP/IP over Carrier Pidgeon" and "Scenic IPv6 Routing"
If you extend the protocol to support SD-cards instead of rolls of paper as the data medium, and appropriate frame and packet sizes, you can get phenomenal bandwidth even if latency and packet drop are still not great.
one classic: A Standard for the Transmission of IP Datagrams on Avian Carriers
> 1. Authors MUST NOT implement bugs.
This, of course, is achieved by writing the software in Rust.
Writing software in Rust avoids, not only memory corruption type bugs, but indeed it is impossible to implement any sort of defect, as long as you write your software in Rust.
/ducks
Or "write it" in Java, there already is a framework to solve your very problem, all you need to do is to configure it in X.. ehm, YAML.
Or just do it all in the frontend, if there is a bug, worst case, user can always reload the page and start over.
Also, never write any specification or documentation. That way, the program is guaranteed to do exactly what it does.
Nah, modern java needs still needs configuration in XML, YAML, _and_ environment variables set in shell scripts somewhere. And maybe stored in your LDAP server too ;)
The temptation to use commit message "fixing coding standard violation" for bugfixes was palpable.
"Software Defects Considered Harmful Unless Fixing Them Requires Pulling Resources Away From Delivering New Features"
"Software Defects Considered Harmful Unless Fixing Them Enables Charging Customers For An Update"
Fixed that for you.
The 70th this week, in fact…
The document is written as though it's just a joke like, haha, of course all software is going to have bugs, it's just a bug bro.
This is false. Software generally doesn't have these kinds of bugs by the time it ships and gets to be the top service in its category.
I am unhappy to read such a glib dismissal of serious, repeated issues that impact my ability to put food in my mouth. 0 out of 10.
I'm not sure how you arrive at this conclusion seeing as how none of the authors work for Patreon or Stripe.
We're laughing at this because it's obvious satire and tongue-in-cheek, and we're laughing at ourselves. No one here that's a programmer strives to produce buggy code, quite the opposite. Frankly, your attack on programmers at large is quite offensive and unnecessary. We're fallible human beings, the same as you (unless you're a bot, but I'm assuming you're a person).
I've personally been woken up overnight 3 times this week to address defects in code I support. Do you think I want that, enjoy it, or celebrate it? Of course not. My full time job is to make the software I work on better: more reliable, faster and use less computing resources to do the work.
> I am unhappy to read such a glib dismissal of serious, repeated issues that impact my ability to put food in my mouth. 0 out of 10.
No one here is dismissing your issues.
I think logicallee is a person trying to be satirical. But from your comment and its sibling, I guess that wasn’t obvious. Poe’s law strikes again (and now I’m wondering if I could be missing satire in your comment… I need more sleep).
I have had a terribly humorless day. The dryness made me chuckle in some deep hidden place.
This seems like it could be the one of the best thing to ever happen to the software industry in decades and has no possible chance of unintended consequences.
Pretending that "higher level code" avoids the bug because you don't see it is just tricking yourself. At the base level, code is just 0, 1, and bug.
— Tony Hoare
“ As an example of the detrimental effects of bugs in physically hard to reach systems: the [NASA] Deep Impact spacecraft [DEEPIMPACT] was rendered inoperable due to a fault in the fault-protection software, which in turn triggered endless computer reboots. Mission control was unable to recover the system from this error condition because no engineers were available on-site. The commute was deemed infeasible due to a lack of reasonably priced commercial transport options in that region of the solar system.”
I think this means that software bugs will be acceptable once there is low cost commercial transportation to every part of the solar system? Has a cost/benefit analysis been done to determine which option is cheaper, eliminating all software bugs versus introducing low cost commercial transportation to every part of the solar system? Is it possible that actively promoting the creation of bugs, while funding remediation efforts for those bugs, including all efforts but especially including low cost commercial transportation to every part of the solar system, would have side effects that would actually pay for the remediation efforts?
Genuine chuckle.
Now gib me a Nobel for the summary above, please. Preferably the one for Saving Mankind.
