Live data from Hacker News

Zero one infinity rule

en.wikipedia.org

101–110 of 149 posts

Re: Zero one infinity rule

#101
A lot of people talking about correctness and performance, but I have a suspicion that most limits in older software had less to do with that and more to do with the fact that things were written in C, where arrays whose size is not known at compile time are just a lot more work for the programmer.

There are cases where the allocations and memcpys when a Go or Java collection grows can be a real problem, but the vast majority of the time it works out fine to leave the size unspecified.

Re: Zero one infinity rule

#103

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 ideal solution to this is the pattern of turning decisions that have to be thought about before you click the button into decisions that can be easily undone.

In this case detect the pathological case and spawn a separate thread that computes the text. Show a progress indicator and an easy cancel button.

Of course, that's harder to implement.

Re: Zero one infinity rule

#104
post #69

Earlier quoted context omitted.

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.

Interestingly this sort of thing falls into a special category where reasoning from first principles is less rigorous than pattern matching to experience. That's because we don't have a good theoretical model.

We're at the point in history where doctor who noticed less patients dying after they wash their hands argues with the doctor with a very erudite explanation of how that's impossible. Maybe someday we'll discover germ theory, but until then we're left to argue anecdotes down in the mud.

Re: Zero one infinity rule

#105
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…

Yes, you need input validation that enforces some kind of limit. But every layer of processing (function calls, RPC…) in the stack from the text entry through the network through the database engine to the disk doesn’t need to be concerned with the 200 character limit for a name. The database can give you an error if the size is exceeded. The input field can warn the user about the limit. But the code that converts f…

Yes, the important thing is to have a data schema that defines the limits and that is enforced at all system boundaries. That way you also identify the cases where the limits may not match those of the protocols you are talking to (mappings between schemata, basically).

Re: Zero one infinity rule

#106

If you took this rule literally though, you’d have to support bigints everywhere. Yet, in practice, setting the limit as INT64_MAX is seen as sufficient to count as “infinity”. In computing, “infinite” is almost never meant literally. When people say “infinite”, they really mean “finite but really really big”

Infinity here means "so big you don't have to think about reaching out". For example, the Rust standard library assumes no system could possibly support more usize::MAX/2 threads, but it worries about you cloning an atomically reference counted pointer usize::MAX times.

Re: Zero one infinity rule

#107

Am 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.

Asked ChatGPT

Yes, you are correct! Ancient Greek has a dual number, which is used specifically for referring to two people or two objects. The dual is a distinct grammatical number, separate from singular and plural.

In the ancient Greek language, nouns, pronouns, adjectives, and verbs all have different forms for singular, dual, and plural numbers. The dual number is used when referring to two things or two people, while the singular number is used for one thing or one person, and the plural number is used for three or more things or people.

The dual number is no longer used in modern Greek, but it was an important feature of the ancient Greek language, which had a rich and complex system of inflectional morphology. Other languages that have a dual number include Old English, Old Norse, Lithuanian, and Slovenian, among others.

Re: Zero one infinity rule

#108
post #82

Earlier quoted context omitted.

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

I want to say, INT_MAX, but I know what you mean. It has been useful that the value varies by implementation (and even by compiler flag, on occasion).

Re: Zero one infinity rule

#109

Am 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.

In Arabic there is the mothanna مثنى (pair) case.

Re: Zero one infinity rule

#110

Earlier quoted context omitted.

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).

“Who you are is inconvenient for me.”

Yes? Why is someone's existence or circumstance de facto an obligation for someone else?

No one lives their life completely accommodating every random stranger's needs.

Post reply on HN