Live data from Hacker News

Zero one infinity rule

en.wikipedia.org

71–80 of 149 posts

Re: Zero one infinity rule

#71
post #69

Earlier quoted context omitted.

>While this has some theoretical merit, What theoretical merit? It sounds like a completely made up rule of thumb based off of a persons anecdotal experience.

Examples of issues Ive seen in the wild because people violate this rule include payroll systems with an arbitrary maximum number of pay codes and review app systems with a static number of review apps. Just like every other heuristic in software engineering, its not a silver bullet, but generally speaking, this principle will serve you well.

So you're confirming what I said. No theoretical basis. You just reaffirmed my position that this rule of thumb is anecdotal with your own anecdotal experiences.

If you look through this very thread there are people talking about anecdotal experiences verifying the opposite effect.

Re: Zero one infinity rule

#72
post #62

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…

Yeah; expected limits are also fantastically useful in performance engineering. It’s very common your code needs to handle an arbitrarily sized input, but 99% of the time the input will be bounded. (Or generally simpler). Special casing the common code path can make a lot of code run much faster. For example, in some code I’m writing at the moment I have lists of integers all over the place. I call them lists - usual…

An arena allocator sounds like it could handle your problem elegantly, without the special cases.

Re: Zero one infinity rule

#73
post #44

I first heard of "no arbitrary limits" in connection with GNU software. It was one of ways that GNU software not only had different licensing than alternatives, but was also usually technically superior. (At the time, there were a lot of different workstation computer vendors, each with their own flavor of Unix. But where GNU tools existed, they'd usually be better than all of the Unix workstation ones. One exception…

One example I recently ran into with large image files, specifically a 24GB PNG file, which of couerse requires much more working memory when uncompressed:

Gimp: Opens this image successfully without complaining. It takes a while and uses lots of swap space but it works.

OSX Preview App: "The file could not be opened. It may be damaged or use a file format that Preview doesn't recognize.

So not only does Preview fail to open the file, it also lies about what the specific issue is. Apparently nobody at Apple ever imagined opening such a large file.

The early Internet flourished in large part because the protocol designers correctly recognized that they couldn't predict or even imagine all the ways people would use their work. "Be conservative in what you send but liberal in what you accept - John Postel" https://en.wikipedia.org/wiki/Robustness_principle

Re: Zero one infinity rule

#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 email activity, you can go a step further and view the statistics by a particular category. Our ability to provide analytics blew up when several customers exploded that to literally millions of categories, most totally unique to a single message.

We no longer release anything as unlimited. If a use case arises, we can always expand the limit, but establishing a limit after the fact is hard and customers don't like having to go back to change integrations.

Re: Zero one infinity rule

#75

Am I the only person who sometimes makes an exception for "two" ?

I'd say that 2 is indeed quite common in Computer science. In graphs, for example, each edge has 2 ends. In an abstract syntax tree, a binary operator has 2 children. All raster images are based on 2 dimensions. A "for each" loop often involves 2 variables: the iterator object and an index. In all such cases it makes sense that a language/ construct/library special-cases 2 elements without generalizing for an arbitra…

Oh, you're right, there are a few other exceptions for other numbers too!

Re: Zero one infinity rule

#76
This is especially relevant when designing systems that may need to scale unpredictably. We dealt with a lot of such growing pains at my company, and then made a rule that every dataset has to be theoretically infinite in size. So for cases like doing a database query, returning lists via an API call etc. you cannot make assumptions like the result set will be small enough to fit in the server's memory or fit on a single web page. Pagination, indexes, search/typeahead are all a must for any case where you expect > 1 result, even though for all practical uses that number may just be 5 or 10. Many years later we are still seeing massive dividends from this rule

Re: Zero one infinity rule

#77

I'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" limit…

Databases used to very much prefer records with fixed sizes. (they still do, but they used to, too) And storage was very, very expensive so these fixed sizes were often the smallest they could conceivably get away with. So there'd be a record in the database, and you might have 10 bytes for the last name, 10 for the first name, and 8 bytes for the password. When I was younger it was super common to see the first 10 letters of my 11 letter last name on official documents. Not long after 9/11 I was hassled by airport security because my last name on my ID "didn't match" the last name on my boarding pass, until an older wiser airport security person explained to him that it was normal for the boarding passes to cut off after 10 characters.

Early versions of BASIC were limited to 2 character variable names. Some would allow you to use longer variable names, but only the first two characters would determine which actual variable it referenced. So if you had the variable JOHN and the variable JOAN they'd alias to the same value. Later versions of BASIC extended this to 6 characters. This was seen as positively extravagant.

Many filesystems used 8.3 filenames; you had 8 characters for the stem and 3 characters for the extension. Sometimes people say that this was just an MSDOS thing but it was common on many other OSs at the time. I'm 90% sure CP/M had this limitation too.

Re: Zero one infinity rule

#78

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…

Totally agreed. I think it's absolutely a best practice to set limits. Code is generally designed to operate within certain "reasonable" performance boundaries, and when it goes outside those you need to think whether code should be rewritten to accomodate it. Just a tiny example, but I regularly deal with long (800+ page) PDF's on my iPad, reading parts of them in the stock Books app. When I select text to highlight…

Maybe “select all” is too easy to click? Might make sense to put it in the “…” menu, and have a “Select All On Page” button front-and-center.

Re: Zero one infinity rule

#79

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…

Putting a user-facing restriction in place is very different from having your underlying infrastructure itself make that assumption. If the product spec says a user will be allowed 5 messages per day, and that's all you design the system to support, you will inevitably run into challenges when the number has to be changed to 20 or 2000 or 20 billion down the line. At that point "but we only used an 8-bit integer because you said the max would be..." isn't a good enough answer, and you are going to be stuck in a very messy rewrite.

Re: Zero one infinity rule

#80

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…

The Wiki page says the problem isn’t with limits, but with arbitrary limits. When a program limits me to 256 of something, it doesn’t seem arbitrary. I’ve heard stories of programmers setting limits to multiples of two simply so nobody asks why.

Although any time I see a limit of 256 I think “are they really using a byte here?”
Post reply on HN