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

21–30 of 149 posts

Re: Zero one infinity rule

#21

Post by crazygringo »

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…

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, the context menu unfortunately puts "select all" directly next to "highlight". Of course, every so often I accidentally hit "select all", and then I have to force-close the app because otherwise it just freezes for 10 minutes as it extracts and selects the text on every single page.

When really, it needs a limit to detect that, hey, if the PDF is over 20 pages long then just don't allow "select all" anymore, because this isn't the right tool for the job.

Re: Zero one infinity rule

#22

Post by cjfd »

hsjqllzlfkf wrote: post #3

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

Well, John Carmack is a game programmer, at least originally. In games one has strong upper limits on how long it can take to calculate the next frame. So, it may very well be that something can be said for this in this context. I am not sure in general, though. If one limits the length of the name of a person in some record one can start waiting until one day a person arrives that has a name that is one character longer and then a programmer needs to get involved to increase the limit. Okay, maybe there exists a ridiculously large maximum name length such that this problem is unlikely to occur. Then one may still have the problem that if all people would have names that approach this limit, the system still might get too slow as well. So maybe we should impose a limit on the sum of all the lengths of all the names in the system. Hmmm... Kind of gets a bit too complicated and arbitrary for my tastes. I think for many systems Carmarcks advice really is not very good.

Re: Zero one infinity rule

#24

Post by travisjungroth »

A metarule for using rules like this: instead of thinking of it as a rule, think of it as an option you should usually consider. You get lot of the benefits and less of the costs if you just ask questions like "Would it be easier to solve for N than 3? Easier to use and maintain?". The answer will never always be yes or no, but you'll be more likely to get the right answer if you ask the question.

Re: Zero one infinity rule

#25

Post by pixl97 »

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…

What should the limits be? And are the limits clear to the users of the system? Are they clear to other components of the system?

I agree we should have limits in software because we don't have unlimited memory and processing time, but I commonly find these limits are encoded by the imagination of the programmer working on the software at the time, and it's often you find limits that were not considered in systems design of the product.

Re: Zero one infinity rule

#27

Post by shoo »

hsjqllzlfkf wrote: post #3

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

> when you design software you should have an idea under what circumstances it will run and optimize for

This philosophy is sometimes referred to as "data-oriented design"

see also: Mike Acton's CppCon 2014 talk: https://www.youtube.com/watch?v=rX0ItVEVjHc

Data-oriented design seems appropriate for shipping high-performance games, and shipping them on schedule and on budget. The goal is not to design and code the algorithm with the best theoretical scalability characteristics - and publish it in a paper, or invent the most mathematically general version of the algorithm to be factored out into a library for use by 100 hypothetical future projects. The goal is not to design a system using hexagonal architecture (or whatever) that can more flexibly accommodate arbitrary changes of requirements in future, at the expense of performance. The source code is not the product that the customers buy, the game is the product.

The goal is to understand the problem you actually have - processing data of a certain finite size or distribution of sizes, on some fixed finite set of target hardware platforms, and figure out how to do this in a way that hits performance targets, with a limited budget of engineering time, to keep moving forward on schedule toward shipping the product.

Re: Zero one infinity rule

#28

Post by alex_sf »

dragontamer wrote: post #17

This 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 would argue your example is a special case of only allowing one.

Re: Zero one infinity rule

#30

Post by PKop »

AlotOfReading wrote: post #12
quelsolaar wrote: post #6

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

Or you can make a tradeoff and simply exclude these outliers from using your product, instead of optimizing for their unique case.
Post reply on HN