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

Understanding the rationale behind a rule when trying to circumvent it

devblogs.microsoft.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Understanding the rationale behind a rule when trying to circumvent it

#31

Post by bigstrat2003 »

zellyn wrote: post #19
techwizrd wrote: post #7

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.

Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!

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.

Re: Understanding the rationale behind a rule when trying to circumvent it

#32

Post by bluGill »

fhdkweig wrote: post #24
bluGill wrote: post #21

Earlier quoted context omitted.

They can be, but you need to take care as sometimes they are misleading and can even drive wrong decisions.

Aesop wrote a lot of fables that had contradictory lessons.

I have more than once in life realized that one of the two contradictory lessons was correct for this situation, but in a different one the other was correct...

Re: Understanding the rationale behind a rule when trying to circumvent it

#33

Post by wat10000 »

harrouet wrote: post #8

There is this famous experiment with 9 monkeys in a room with a banana attached to the ceiling and a scale. First day, a monkey climbs the scale, gets the banana and is happy. Second day, they start spraying whomever gets on the scale. Monkeys hate this. They learn not to climb. Third day, they take a monkey out and replace with another. The new monkey sees a banana up there and tries climbing the scale. He literally…

It's funny how this monkey experiment is often trotted out as "people blindly follow the rules without knowing why," when the rule learned by the monkeys is a really good rule (it prevents a malevolent entity beyond your understanding from attacking you!), and the only reason the monkeys don't understand the "why" at the end of the experiment is because they don't have language.

The lessons I'd take away from the experiment would be 1) be sure to tell people why the rules exist, but also 2) follow the rules even if there's no apparent reason for them, otherwise you might get smacked down by some unimaginably powerful entity you're barely even aware of.

Re: Understanding the rationale behind a rule when trying to circumvent it

#34

Post by frandroid »

bigstrat2003 wrote: post #31
zellyn wrote: post #19

Earlier quoted context omitted.

Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!

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 inte…

So we can call this one Chen's Fence

Re: Understanding the rationale behind a rule when trying to circumvent it

#35

Post by Bjartr »

deliciousturkey wrote: post #27

I really wish Windows had a way to show what kernel callbacks are registered and execute on each call. Even better would be to have actual timing data on these callback. Using that one could much more easily to debug and potentially uninstall misbehaving software.

You may already know about it, but for those that aren't aware of it, Windows' Event Tracing system can give a pretty deep view into identifying misbehaving software. It probably doesn't cover everything you wish you could track, and not quite with the level of directness you're asking for, but it's helped me track down weird slowdowns and hangs on my computer on a few different occasions.

There's a third party tool for collecting and examining such traces easier called UIforETW

https://randomascii.wordpress.com/2015/09/24/etw-central/

Re: Understanding the rationale behind a rule when trying to circumvent it

#36

Post by csours »

JohnMakin wrote: post #3

Am reminded reading this of an esteemed and since passed away colleague who had written windows driver code since the dos days and may have had decades of insanely archaic knowledge die with him - when working on a difficult piece of windows driver code years ago, he said to me in a thick eastern europe accent as best i can remember “you make the primary mistake of thinking anything in windows makes sense. once you a…

Implemented by intention vs implemented by history

Re: Understanding the rationale behind a rule when trying to circumvent it

#37

Post by kgwxd »

zellyn wrote: post #19
techwizrd wrote: post #7

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.

Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!

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.

Re: Understanding the rationale behind a rule when trying to circumvent it

#38

Post by ralferoo »

bigstrat2003 wrote: post #31
zellyn wrote: post #19

Earlier quoted context omitted.

Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!

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 inte…

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.

Post reply on HN