Live data from Hacker News

Hyrum's Law

hyrumslaw.com

61–70 of 71 posts

Re: Hyrum's Law

#61
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?

Multiple implementations of the same interface.

When people don't know which implementation will be used, they tend to stick to the standard or the documentation.

We see this in places like the C language or in Common Lisp. Library writers must take into account that the implementation they use their library on may not be the same as the implementation their users will use.

Re: Hyrum's Law

#62
post #60

Earlier quoted context omitted.

Yeah, no, humans can't hold complicated documentation in their heads. The whole experience of being human is finding a way to get by with a simple model which fits in your head but isn't wrong enough to cause trouble, and that's exactly what Hyrum is reflecting. What you're getting at is the C++ "Just don't make any mistakes" approach to software engineering, which is a disaster that has cost our civilisation a great…

That is emphatically not what I am "getting at". I cannot express my opposition to that approach strongly enough. I do not believe that the place people should hold documentation is "in their heads". I do not believe that Hyrum's "Law" is helpful in getting to a situation where people's beliefs about what software will do match reality. This isn't the first time I've come across people (particularly around the Rust c…

If you accept that people are going to rely on things you didn't contract for by mistake then you're right back to Hyrum's Law. It's that easy.

Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world that some people don't like. So no, the law isn't going to fix people's beliefs any more than Newton's Laws did for weird beliefs about motion.

I'd actually say the importance of documentation is better understood in the Rust community. Including, which is vital here, the importance of not relying on humans remembering to read all this text when you've got better options. Rust has documentation telling you that you're not promised whether or not some elements which compare equal are swapped when you [T]::sort_unstable. But it doesn't need to spend a lot of time warning you that that you shouldn't [T]::sort_unstable a slice of type T which doesn't even claim to have ordering, because the compiler rejects such nonsense anyway.

Indeed even the naming is an example. In C++ that function is just named sort. Because you know, an unstable sort is faster†. Will it sometimes surprise some poor noob because it's unstable? Sure, but apparently that's OK because if they had read and properly digested the documentation they would know it's an unstable sort. I suggest if the function were named better the user is much less likely to make this mistake before they even glance at the documentation.

† Typically

Re: Hyrum's Law

#63
post #60

Earlier quoted context omitted.

That is emphatically not what I am "getting at". I cannot express my opposition to that approach strongly enough. I do not believe that the place people should hold documentation is "in their heads". I do not believe that Hyrum's "Law" is helpful in getting to a situation where people's beliefs about what software will do match reality. This isn't the first time I've come across people (particularly around the Rust c…

If you accept that people are going to rely on things you didn't contract for by mistake then you're right back to Hyrum's Law. It's that easy. Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world that some people don't like. So no, the law isn't going to fix people's beliefs any more than Newton's Laws did for weird beliefs about motion. I'd actuall…

> Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world

But it isn't.

Neither Hyrum, nor anybody else, has ever seen a system where "all observable behaviors" were depended on by somebody. And if they somehow had, they couldn't know that it hadn't mattered how clear the documentation had been.

There are two much weaker statements which I think are true:

- "No matter how carefully you document your contracts, it will happen from time to time that you leave something unstated and people reasonably guess wrongly what you intended."

- "No matter how carefully you document your contracts, from time to time some people will choose to rely on things you didn't promise, without caring about that."

As well as actually being true, these statements have the advantage of not falsely implying that you can't improve the situation by putting effort into documentation.

Re: Hyrum's Law

#65
post #63

Earlier quoted context omitted.

If you accept that people are going to rely on things you didn't contract for by mistake then you're right back to Hyrum's Law. It's that easy. Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world that some people don't like. So no, the law isn't going to fix people's beliefs any more than Newton's Laws did for weird beliefs about motion. I'd actuall…

> Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world But it isn't. Neither Hyrum, nor anybody else, has ever seen a system where "all observable behaviors" were depended on by somebody. And if they somehow had, they couldn't know that it hadn't mattered how clear the documentation had been. There are two much weaker statements which I think are tru…

Surely your statements are just corollaries which are noticeable with fewer users ? Hyrum's Law is more succinct because of its prefix, "With a sufficient number of users".

And I think we do see small systems where all observable behaviors are indeed depended upon, lots of trivial systems exhibit exactly this property, it's just it doesn't trigger the part of Hyrum's Law that apparently annoys you - "it does not matter what you promise in the contract" because if anybody did write a contract it would state the entire behavior, no surprises are possible.

And that permits a valuable conclusion from Hyrum's law. It's better to design my interface so that it's so simple any fool will use it right, than to document all the weird sharp edges of my interface so that I can potentially win an "Um, actually" episode each time a fool cuts themselves on the sharp edges. That's not always possible but often in our industry it's apparent nobody was even trying.

Re: Hyrum's Law

#66
post #28

Earlier quoted context omitted.

> I guess the linux kernel still supprorting binaries from ages ago might be too. Actually it's Linus making sure that kernel changes don't break old binaries from ages ago. And in fact there were many cases of undocumented behavior being relied on by apps, and Linus would send big rants about how you never break userspace, whether the behavior is documented or not. Don't have any of them on hand right now, unfortuna…

This is probably the most famous one: https://lkml.org/lkml/2012/12/23/75

Classic!

Re: Hyrum's Law

#67
post #57

Earlier quoted context omitted.

Hyrum still made a website called "Hyrum's Law." That's just graceless, at best.

This is a common pattern in history: - Person 1 makes an observation that they assert is true - Person 2 refers to this observation as “Person 1’s Law” for convenience when discussing the observation and whether or not it is true. There’s nothing wrong or “graceless” with Person 1 then using the term themselves, even for the purpose of arguing in favor of their assertion (which is what this web page is doing). Some e…

Yeah this is just medler’s Law in action.

Re: Hyrum's Law

#68
post #9
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?

> “Generate Random Extensions And Sustain Extensibility” This should get a re-submit on HN (0 comments - https://news.ycombinator.com/item?id=16149534 4 years ago) I wonder if it would allow for easter eggs again. Would the fabled story between Larry Osterman and Raymond Chen's Exchange POP3 server easter egg fall within GREASE - https://learn.microsoft.com/en-us/archive/blogs/larryosterma...

I tried to figure out how it credit it to you, but it was too complicated, so just I posted it here as me: https://news.ycombinator.com/item?id=39416277

Re: Hyrum's Law

#69
post #63

Earlier quoted context omitted.

If you accept that people are going to rely on things you didn't contract for by mistake then you're right back to Hyrum's Law. It's that easy. Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world that some people don't like. So no, the law isn't going to fix people's beliefs any more than Newton's Laws did for weird beliefs about motion. I'd actuall…

> Hyrum's Law isn't about what you should do, or how things should be, it's telling you an observable fact about our world But it isn't. Neither Hyrum, nor anybody else, has ever seen a system where "all observable behaviors" were depended on by somebody. And if they somehow had, they couldn't know that it hadn't mattered how clear the documentation had been. There are two much weaker statements which I think are tru…

Laws of nature are not prescriptive: they only predict what will happen. It is up to us to fend off consequences we don't want, by whatever means we can muster. The law means that calling out non-promises in the name is favored. But that is often not practical.
Post reply on HN