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

Zero one infinity rule

en.wikipedia.org

Post reply on HN
Print view View original

81–90 of 149 posts

Re: Zero one infinity rule

#81

Post by bee_rider »

sethammons wrote: post #74

I've been working on high scale systems for over a decade. An early lesson was to put limits on everything. Because we started without them, customers leveraged the lack of limits, and cardinality became a huge problem. Real example: at SendGrid, you can attach "categories" to emails which can help organize your email analytics by enabling you to group emails by type. Just as you can view the statistics on all your e…

Was it hurting anything to have millions of categories? I mean, I’d assume the metrics interface they’d gotten from you would be essentially useless, but if they had some workflow they worked, why not let them have it?

Re: Zero one infinity rule

#82

Post by hinkley »

solveit wrote: post #64
zeroonetwothree wrote: post #13

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

I think a better way to formulate the same rule of thumb is that zero, one, and infinity are the only numbers that don't need to be justified . You should always have an answer to the question "why 5000 and not 6000?" Of course, the justification can be as simple as "it has to be some number and 5000 is as good as any", but that opens the door to the discussion of whether 5000 really is as good as any other number, w…

You can’t justify infinity.

The practical version of the rule is “zero, one, and out of memory”.

The data structure doesn’t care about 12,001, but your real system does.

Re: Zero one infinity rule

#83

Post by mellavora »

adhesive_wombat wrote: post #49
stefan_ wrote: post #32

Earlier quoted context omitted.

Nope. "No formal limit" or "infinity" is just another way of saying "dynamic memory allocation". There is a reason you usually find this advice in game adjacent places; to punt everything to the dynamic memory allocator makes it very difficult to know if you are keeping within the memory-starved limits of e.g. the game console you are developing for, or on mobile to keep a garbage collector from stepping in and ruini…

"Nope." An "algorithm" can be about things other than memory allocation. Say you have a collection of sensors the you poll. ZOI is saying that the system that polls them shouldn't[1] have some kind of hard assumption that there will only ever be, say, specifically 4. You could still statically allocate the storage on a given system, for example in an embedded system where the software is compile-time configured for a…

> If you follow every rule you subscribe to dogmatically, then you're doing something more akin to religion

My impression of religion is dogmatically following only a changeable subset of the rules you subscribe to, where subscribe means "they are in our special book"

Re: Zero one infinity rule

#84

Post by mellavora »

GauntletWizard wrote: post #54
layer8 wrote: post #40

Earlier quoted context omitted.

There should be limits. What if someone pastes the text of the bible into the name field? What if you want to send an email containing the name, and you hit the maximum email size accepted by the SMTP server (they all have a limit)? What if you want to send a postal letter and print the name on the envelope? Not setting explicit limits either means that you still have implicit limits, but you don’t know what they are…

I have legitimately used the complete works of William Shakespeare, unabridged, as a password. Even that is in megabytes, and not significant load for bcrypt2. Not that there should be no limits at all, but the upper bound should be relatively high.

Now all I have to do is guess which order you used them in, and I'll have full access to your system!

Re: Zero one infinity rule

#86

Post by lolcatuser »

hinkley wrote: post #82
solveit wrote: post #64

Earlier quoted context omitted.

I think a better way to formulate the same rule of thumb is that zero, one, and infinity are the only numbers that don't need to be justified . You should always have an answer to the question "why 5000 and not 6000?" Of course, the justification can be as simple as "it has to be some number and 5000 is as good as any", but that opens the door to the discussion of whether 5000 really is as good as any other number, w…

You can’t justify infinity. The practical version of the rule is “zero, one, and out of memory”. The data structure doesn’t care about 12,001, but your real system does.

You absolutely can justify infinity - even if your real system can't represent numbers larger than X, you can't guarantee that won't change in the future.

For example, in C, integers have minimum sizes, but no maximum. We're lucky nobody ever went, "well, our PDP-11 can only go up to 2^16, so let's set the maximum there."

That's not to say it doesn't make sense to limit things after a certain point, but you'd damn well better be able to justify it, especially if you're using a recursive data structure that could absolutely grow to infinity if needed.

Re: Zero one infinity rule

#87

Post by renewiltord »

This is easily misunderstood (e.g. many peer comments). It's a design structure heuristic. It isn't about the limit in there. It's about the style of algorithm or data structure.

An obvious example is something like you want to support a primary data source and if something is missing there you want to fall back.

Either you implement it is as no fallback, you implement it as one fallback, or you write your code to support arbitrary fallbacks. What you shouldn't do is specifically support two fallbacks.

Another example is something like say you want to have badges on a user. You want to store this in the backend and then you want to display badges next to their comment.

Suppose you decide you want to allow a maximum of 3 badges per user.

Conforming to 0-1-infinity is about having a badge[]. Not conforming to it is having, on your User, a badge1, badge2, and badge3.

The two rules of 0-1-infinity and always-have-a-limit are orthogonal.

Re: Zero one infinity rule

#88

Post by hammock »

zeroonetwothree wrote: post #13

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

>limits are quite useful to catch bugs

Can be solved with tests instead though.

Speed limits on roads are useful in catching unsafe driving behavior; but if every car actually had speed governors installed, that couldn’t be overcome, it should be clear that this is a suboptimal solution.

Arbitrary limits written into code will eventually be refactored into ZOI, one way or another

Post reply on HN