Am I the only person who sometimes makes an exception for "two" ?
i fairly regularly want pairwise, yep.
Zero one infinity rule
11–20 of 149 posts
Re: Zero one infinity rule
#12John Carmack argued the opposite. He said he would hardcore limits into his data structures. Limits that would never be hit under normal operating circumstances. He argued that when you design software you should have an idea under what circumstances it will run and optimize for those. The fact that people normally don't do this, is why software often lags - that algo you implemented worked worked just fine when it's…
Ive come to agree with this. Say you have a struct that contains a name. If you limit the name size to say 64 bytes, then you can store it in the struct, otherwise you need to have a separate allocation and an indirection. This makes the code slower, more error prone and more complex to use. So think hard of when “infinite” is justified.
You should also be careful about incorrectly imposing limits on human input, as every "falsehoods programmers should know about x" repeatedly hits on. To continue the name example, there are people with legal names and titles that take far more than 64 bytes to store and truncation is not an appropriate solution. You should store the entire thing, even if that's a small bit more difficult technically. The other limit also applies. Some people don't have any characters in their legal names at all, like my mother (birth certificate name was blank).
Re: Zero one infinity rule
#13While this has some theoretical merit, IME, limits are quite useful to catch bugs (or prevent degenerate cases). For example I was recently working on a permissions system wherein there can be members of groups. I set a reasonable limit on the size of a group based on a maximum of actual usage and what I could foresee being reasonable. A few days later, this limit was triggered, and I got a bug report. But it turned out there was some bad caller that had essentially an infinite loop that was adding more and more members to the group. Without the limit this probably would only have detected after it cascaded and caused other failures.
As another example, Facebook famously had (maybe still has? I have no idea) a limit of 5,000 friends. This was based on the idea that you were supposed to be friends with people you actually kind of know at least a little bit, which would probably fit within 5,000 for most people. After some more popular users started hitting the limit, it led to the development of public profiles/pages as an alternative product to handle that use case. So in this case the limit allowed the company to identify a new market that they could better serve in an alternative way.
BTW, the George Gamow book that the name comes from (One, Two, Three… Infinity) is a great read for anyone interested in popular descriptions of physics or math. He also lived a very interesting life, I would recommend his autobiography "My World Line".
Re: Zero one infinity rule
#14John Carmack argued the opposite. He said he would hardcore limits into his data structures. Limits that would never be hit under normal operating circumstances. He argued that when you design software you should have an idea under what circumstances it will run and optimize for those. The fact that people normally don't do this, is why software often lags - that algo you implemented worked worked just fine when it's…
Ive come to agree with this. Say you have a struct that contains a name. If you limit the name size to say 64 bytes, then you can store it in the struct, otherwise you need to have a separate allocation and an indirection. This makes the code slower, more error prone and more complex to use. So think hard of when “infinite” is justified.
This is true, but note that the "Zero one infinity rule" only applies to the number of items, not the size of an item. Limits on size are a lot more typical anyway.
(Yes I know someone will point out that to store a list of items requires a linear amount of space, so therefore an unbounded number of items inherently implies an unbounded amount of space)
Re: Zero one infinity rule
#15Earlier quoted context omitted.
Ive come to agree with this. Say you have a struct that contains a name. If you limit the name size to say 64 bytes, then you can store it in the struct, otherwise you need to have a separate allocation and an indirection. This makes the code slower, more error prone and more complex to use. So think hard of when “infinite” is justified.
You should also be careful about incorrectly imposing limits on human input, as every "falsehoods programmers should know about x" repeatedly hits on. To continue the name example, there are people with legal names and titles that take far more than 64 bytes to store and truncation is not an appropriate solution. You should store the entire thing, even if that's a small bit more difficult technically. The other limit…
I think "should" is a bit strong here. There are always tradeoffs. Having support for very long names can cause other problems, like the opportunity for abuse, making it hard to format UIs, making human inspection of data much harder, or even limiting algorithmic efficiency.
For example, US Passports have a relatively small limit for name length (I think it's around 20 characters each for first/middle/last).
Re: Zero one infinity rule
#16I think this is something programmers intuitively learn pretty quickly (in fact I'm only just learning that there is actually a name for this idea), but it's an interesting principle to explain to non-developers.
Back when I was doing agency work, on more than one occasion I had clients question why modifying some entity to permit multiple related entities instead of one would be more work than they were anticipating.
The question was usually along the lines of "would it help if we were to limit related $foobars to three?". But of course, from a structural perspective supporting three related records is usually exactly the same amount of work as supporting arbitrary amounts. Yeah I could probably hack in some fixed amount of extra records, but that's just going to create an increasingly large mess when your business grows and you realise three...twelve...one hundred wasn't enough. Might as well do it properly from the start.
Re: Zero one infinity rule
#17This is probably a rule I believed in as a beginner, and completely don't believe in anymore today.
Lets take a look at an exceptionally well designed system: single-error correction double-error detection codes. Also known as "ECC RAM". The implementation of this only works for *exactly* 64 bits + 8-parity bits.
Now sure, we can talk about how we can generalize SECED ECC to different numbers of bits or whatever. But I'll also point out that the only implementation in widespread use is ECC Memory, the 64-bits + 8-parity bits (72-bits total) implementation.
Re: Zero one infinity rule
#18Am I the only person who sometimes makes an exception for "two" ?
Two is quite relevant for relationships
Re: Zero one infinity rule
#19I've read the article but I'm having trouble understanding the context of what this was in response to. The article quotes:
> I formulated it in the early 70s, when I was working on programming language design and annoyed by all the arbitrary numbers that appeared in some of the languages of the day.
Was it just an issue with languages in the 70's then? Because I'm struggling to think of any "arbitrary number" limits in modern languages.
Obviously we have numerical limits depending on if a variable is a signed 32-bit integer or whatever. But those aren't arbitrary.
Like would older languages just arbitrarily say there couldn't be more than 100 elements in an array, or something?
Re: Zero one infinity rule
#20Am I the only person who sometimes makes an exception for "two" ?
I seem to recall that there are certain languages (human languages) that have cases specifically for talking about pairs of objects, situated semantically between singular and plural. I think one of these is an archaic form of Greek, maybe ancient or Hellenistic.