5 ms·

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 permiss

• crazygringo 4y ago
  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.
  • psychphysic 4y ago
    Although that's also ripe for the annoyance of not being able to select all in border cases. I'm much in favour of don't fuck with the basics (i.e. the core expect feature UI like select, copy and paste.).
    • deleted 4y ago
      [deleted]
  • bee_rider 4y ago
    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.
  • iudqnolq 4y ago
    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.
  • DougBTX 4y ago
    A soft limit would work well here, a prompt saying, “There are a large number of pages, it will take a while to select them all. Do you want to continue?” then it informs the user, rather than (maybe) artificially limiting them.
• pixl97 4y ago
  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.
• HervalFreire 4y ago
  >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.
  • chazu 4y ago
    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.
    • HervalFreire 4y ago
      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.
      • iudqnolq 4y ago
        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.
        • HervalFreire 4y ago
          You recall mercury? Mercury was used by doctors for years as medicine and it was validated by anecdotal experiences. But it really had the complete opposite effect. It killed people. That is the reliability of anecdotes and an illustration of how delusional humans and "experts" are. Nowadays there's still no complete "theory" for medical science. We have partial theories like biochemistry but it's not a complete theory as in we can't completely derive which chemicals can cure which disease via a formal model. In fact given the complexity of reality we may never ever have a formal model for medicine and as such we most likely will have to forever rely on asymmetrical nature of science. Computing is bounded in a simulated universe axioms and logic. Computers are in actuality a part of reality but we try to use them as if they are seperate universes of pure logic and math games. To say that something has "some theoretical basis" is a very precise statement in computing because unlike medicine it is VERY possible for entities in such a bounded system to have a complete formal theory. The problem is the Zero one infinity rule is not such a thing. The statement to say it has "some theoretical basis" is therefore completely false. Especially given the fact that in this thread there are a bunch of counter examples and I myself don't fully agree with it. How do you know this Zero one infinite rule is not just some form of mercury in disguise? My disagreement, however, is NOT the point. The point is that this rule currently has ZERO theoretical basis. Additionally given the existence of counter examples, it likely will ALWAYS have zero theoretical basis. I don't completely deny the validity of anecdotal evidence, but, again, the claim made initially by the GP is false.
• pyuser583 4y ago
  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.
  • bee_rider 4y ago
    Although any time I see a limit of 256 I think “are they really using a byte here?”
• josephg 4y ago
  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 - usually they only have 1 element. Sometimes they have 2 elements (10%) and very occasionally more than 2 elements or they’re empty (<1%). If I used a language like Javascript, I’d use Arrays. But arrays are quite expensive performance wise - they need to be allocated and tracked by the GC and the array contents are stored indirectly. Instead, I’m using an array type which stores up to 2 items inline in the container object (or the stack) without allocating. It only allocates memory on the heap when there are 3 or more items. This decreases allocations by 2 orders of magnitude, which makes a really big difference for performance in my library. And my code is just as readable. I’m using the smallvec crate. There’s plenty of libraries in C and Rust for this sort of thing in arrays and strings. Swift (like obj-c before it) builds small string optimizations into the standard library. I think that’s a great idea. https://crates.io/crates/smallvec https://crates.io/crates/smallvec
  • citizen_friend 4y ago
    An arena allocator sounds like it could handle your problem elegantly, without the special cases.
    • josephg 4y ago
      I've thought about that. While processing, yes - an arena allocator is a better fit. But my data is loaded from disk & held in memory while its manipulated by consumers of my API. Given the lifetime is determined by the caller, there's no obvious arena to allocate from. I could put the whole thing into a long lived arena - but unless I'm careful, some operations would leak memory. But it would definitely be better from a performance standpoint. Using smallvec, every time these values are read or written the code needs to check if the value is "spilled" or not. And I think there's a lot of code monomorphization involved too - using a vec in an arena would probably make my binary a fair bit smaller.
• solveit 4y ago
  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, which is often surprisingly enlightening.
  • hinkley 4y ago
    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.
    • lolcatuser 4y ago
      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.
      • w0mbat 4y ago
        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).
        • hinkley 4y ago
          I think you both need to watch some YouTube math videos on what exactly infinity means. As Everyday Maths put it, it’s not “count until you can’t count anymore and then add one to the number”. That’s the sort of wrong frame of thinking that makes you think that an infinite pile of hundred dollar bills is worth more than an infinite pile of one dollar bills. They are both worth $infinity. We don’t have any algorithms that can deal with infinity, so stop pretending like we do. And we couldn’t build one unless the universe is infinite and expansions turns out to be incorrect. So no infinity in computer data structures.
• hammock 4y ago
  >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
• deleted 4y ago
  [deleted]
• Cthulhu_ 4y ago
  A lot of limits are set explicitly to ensure things don't go haywire, think things like rotating log files. Other ones have to do with display logic, that is, there's only space for X characters in a title section. Although that can be handled with CSS, it's still sane to set a limit so you don't get megabytes of garbage data cut off by CSS.
• renox 4y ago
  Yes, that's why I think than 'checked int64' are a far better default for language integers than 'big ints', because if you overflow an int64, it's most likely a bug/an hacking attempt.
• hinkley 4y ago
  Someone implemented a fairly naive DAG in our system that sometimes sprouts cycles. The cheapest way to catch cycles is to limit the graph size to 10x nominal. If we ever encountered a request that was legitimately that far from normal, we would most likely time out during the subsequent work anyway, because processing time grows faster than n and our timeout is only about 20x our mean response time. If there is a loop, we will hit the limit while evaluating the cycle because it’s a DFS. With a BFS we could hit the limit in a sibling of the problematic node. Scheduling budgets are how most people avoid the halting problem. You set a fixed multiple of expected halting time and work hard to make sure that’s your p99 time instead of your p75 time, and stop trying to violate core principles of computational theory.
• hakre 4y ago
  > limits are quite useful to catch bugs (or prevent degenerate cases) Sure, this is why code designed by ZOI rule has those straight forward test cases: none, one, some, many aaaand crash (at most). and for safeguard of correct use (limits as undefined behaviour) many languages have assertions.