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

31–40 of 149 posts

Re: Zero one infinity rule

#31

Post by meghan_rain »

quelsolaar wrote: post #6
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…

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.

> more error prone

not when using Rust ;-)

Re: Zero one infinity rule

#32

Post by stefan_ »

adhesive_wombat wrote: post #8
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…

You can still have both: an algorithm that technically has no formal numerical limit, but have warnings or errors when it reaches some condition that is clearly outside the design scope. For example, you might have a system that warns somehow if you start inserting items at the front of a vector with over a million items (when you originally expected the vector to be used for tens of items). If the structure is sudde…

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 ruining your day.

Re: Zero one infinity rule

#33

Post by xlii »

I have a feeling that a lot of commenters mix up structure design with structure implementation.

Rule talks about the design (and I find approach interesting) yet implementation can (and most likely should) be limited.

E.g. we are designing a world. In this design we say children can have toys. It doesn’t make sense to design universe so that children are limited to 5 toys or any other arbitrary number. But no room can fit infinite number of toys so implementation is limited. For some it’s 500 toys but for some it’s 500.000 toys.

Names or parents are good real world examples. Sure, most people have 2 parents pr at most 2 names but this rule argues that if there’s more than one it shouldn’t be limited at all (which also makes sense in real life even though IT system might limit names to 256 characters because hardware).

Re: Zero one infinity rule

#34

Post by mhh__ »

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…

> 1m keys

As opposed to not working at all?

Re: Zero one infinity rule

#36

Post by quelsolaar »

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…

Who said anything about the name being the name of a person?

Re: Zero one infinity rule

#37

Post by eternalban »

xlii wrote: post #33

I have a feeling that a lot of commenters mix up structure design with structure implementation. Rule talks about the design (and I find approach interesting) yet implementation can (and most likely should) be limited. E.g. we are designing a world. In this design we say children can have toys. It doesn’t make sense to design universe so that children are limited to 5 toys or any other arbitrary number. But no room c…

Then change the name of the rule :)

Zero, One, or Many. I think that would satisfy all concerned.

Re: Zero one infinity rule

#38

Post by gdprrrr »

crazygringo wrote: post #19

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…

Early C compilers had a limit of 6 characters for an identifier

Re: Zero one infinity rule

#40

Post by layer8 »

cjfd wrote: post #22
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 lo…

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 and where and when you’ll run into them, or it means you’re opening yourself up to DoS attacks, because your database or your backups or your AWS bill will run amok.

Post reply on HN