Like a real-time voice changer? I'm sure some such thing exists. I'm building a real-time voice changer for RPG sessions because I'm terrible at doing voices. Half my NPCs all sound the same!
I'm working on a side project to clean up and fix EPUB files with transcription errors, incomplete or inaccurate metadata, and other issues. Users can accept/reject/edit the fixes as they go through it. I have the command-line interface and TUI working (thanks to Ratatui), but I'm still working on a Calibre plugin and web-based version using WASM.
They've also been pushing digital-only PS5s and PS5 Pro so there are fewer reasons to get a disk if you have no disk drive. They have created the problem that they are "solving."
The PS5 is great. We have a PS5 and PS5 Pro, both with disk drives (internal or external). But I really hate this policy. My brother comes over regularly to watch my pets, and he can simply bring a couple of his PS5 games over and play them rather than rebuying them and digitally downloading them. This breaks the in-person social aspect of gaming and game sharing that we've become accustomed to for decades.
This seems adjacent to Chesterton's Fence, though maybe not the canonical form of it.
For anyone not familiar with the term, Chesterton's Fence is the idea that you should understand why a rule exists before trying to remove it or work around it: https://fs.blog/chestertons-fence/
Here the issue is not that the rule was removed, but that the code followed the wording while missing the reason the rule existed.
It's also a mistake to only focus on the original intent of putting something in. It's quite common that other things comes to depend on that thing even after the original reason is gone (or even that the thing works but not for the reason that was thought).
2. Understand why that rule is in place before proceeding
This article deals with the second part, but not the first. So it is only about about half of Chesterton's fence at best.
In these examples, a rule (avoid blocking calls) is in place to guide the programmer to a performant system. Programmers apparently thought that if they found a way to avoid directly blocking calls, but managed to indirectly block, they had still obeyed the rule. And strictly by the most narrow reading of the rule they had obeyed it. But they had defeated the purpose of the rule.
So definitely Chesterton's Fence adjacent, but not Chesterton's Fence itself.
It's not about Chesterton's Fence, though I thought so at first due to the title wording. The developers Raymond is referring to actually weren't trying to circumvent a rule. They followed the rules to the letter, but whoever made the rule didn't adequately document the spirit of the rule. So when the letter of the rule turned out to be insufficient, the devs couldn't really know that their solution violated the intent behind the rule.
Yeah, I agree. Often prohibitions are made without any context as to why they exist.
I remember back in the 80s when I was a young kid (maybe 8 or 9) and I'd just started learning Z80 machine code. The manual for the computer had a strongly worded "do not use the alternate register set" (probably bolded and all caps), and sure enough the one time I tried, the computer crashed. I decided that it must be dangerous, and never tried that again.
It was only years later when I discovered that the OS firmware used the alternate registers in the interrupt routines, and assumed that they were always set a certain way (in particular, BC was used to ensure ROM was visible not RAM before jumping into it, and on return RAM was paged back based on the existing contents of that register). So, if the warning had said "don't use the alternate register set unless you disable interrupts and save/restore the registers before re-enabling them", it'd have indicated what the problem was and why. Additionally, I think somewhere else there was a dire warning about "disabling interrupts for too long" with no indication what was too long or what problems it might cause. In reality the only thing it affected was the built in system clock which was only used by BASIC and the sound firmware, so for almost everything you might want to do it didn't matter in the slightest. (Actually, there was a slight caveat with the hardware that you actually did need to acknowledge the vertical sync interrupt within a certain time frame or it would fire at the wrong time on the next frame, but even if you did that, it would correct itself by the second frame, so again was entirely unimportant, especially if you never planned to return to BASIC).
As well as not explaining the why, which helps understanding of the system generally, a list of prohibitions makes experimenting with the computer seem scary. One of the best things about old 8-bit home computers was that there was very little you could accidentally do in software that'd actually cause any lasting damage, unless you were deliberately doing stuff like toggling relays as fast as possible or fiddling with the monitor sync signals, sending excessively out-of-range timings and then left the monitor for a long time.
Maybe because every concept has some plonkers name associated with it. The ideas stand on their own. It does not matter who said what, when. I'm pretty sure the only reason people feel the urge to interrupt a conversation to drop names like that is to boast about their useless knowledge.
I agree. Their fountain pens and inks are just rock solid, and I've practically never run into an issue with any of mine. I wish more companies would obsess over the details like Pilot does.
