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

Hyrum's Law

hyrumslaw.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Hyrum's Law

#31

Post by kazinator »

salawat wrote: post #23
jackblemming wrote: post #8

Earlier quoted context omitted.

Telling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.

You don't get to decide what is and isn't an implementation detail. And lets be real. There is no contract, and any one that is made will inevitably be broken.

That depends entirely on the economics of the situation. Like who violates the contract, and how much business they represent.

Or other measure of their importance.

Does the C library change break a major distro? Or just some obscure program with three users?

Re: Hyrum's Law

#32

Post by tomrod »

Hyrum and I went to grad school together! Different programs but neighbors. Really enjoyed Sunday barbecues with the guy. He's whip smart.

Re: Hyrum's Law

#33

Post by havermeyer »

cpeterso wrote: post #2

What are some fun or unusual examples of Hyrum’s Law that you’ve run into? Were you the user, inadvertently depending on some implementation detail? Or were users depending on your implementation’s details?

I reviewed a CL from Hyrum at Google where he was trying to remove a `set_timeout(float)` method in favor of `set_timeout(absl::Duration)` and changed the former to delegate to the latter. It turned out that there was some special handling of inf/nan in the legacy API, despite no mention in the documentation, and his CL broke a number of tests. It was amusing to experience Hyrum's law so directly :)

Re: Hyrum's Law

#34

Post by summerlight »

jackblemming wrote: post #8
cpeterso wrote: post #3

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?

Telling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.

When the clients have the power (e.g. a team that contributes to 90% of company's revenue), breaking the contract is often non-option from the beginning.

Re: Hyrum's Law

#37

Post by saghm »

dgacmu wrote: post #11
cpeterso wrote: post #3

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?

The Go hash table approach is similar to this: it's randomizedish but not strongly random enough to depend on it being actually random... https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-r... (Which I find a hilarious second order example of Hyrum's law - if you add true randomness to prevent people from depending on the iteration order, they might use it as a way to randomly access items in the map!)

This was mostly annoying because Go doesn't really provide any ordered map in std (and for while didn't give you generics, which are needed to make a general-purpose one that's perfomant). I feel like the best response to people relying on the order of iteration is to recognize that as a valid need an provide it via a separate type.

Re: Hyrum's Law

#38

Post by c0pium »

jackblemming wrote: post #8
cpeterso wrote: post #3

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?

Telling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.

Ah yes, the “you’re holding it wrong” strategy.

Re: Hyrum's Law

#39

Post by pkasting »

yau8edq12i wrote: post #36

If I understand correctly, it's the actual guy named "Hyrum" who made this website called "Hyrum's law"...? Geez.

Titus Winters is actually the person who named this "Hyrum's Law" and popularized it as such.

Re: Hyrum's Law

#40

Post by quectophoton »

cpeterso wrote: post #2

What are some fun or unusual examples of Hyrum’s Law that you’ve run into? Were you the user, inadvertently depending on some implementation detail? Or were users depending on your implementation’s details?

Let's just say "this HTTP endpoint expects its body to be JSON" and "we use a library that allows invalid JSON" (e.g. trailing commas) aren't exactly a good combination.

Code easily ends up depending on the specific library's quirks and config, regardless of what the actual contract said.

Post reply on HN