3 ms·

> There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reaso

by moring 4y ago

> There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take. What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.

alkonaut 4y ago
Let's take another example. E.g. if you have a progress bar for doing a set of 5 git operations you don't know whether the 3rd might start some housekeeping. For some tools (such as git) it might be possible to force this automatic housekeeping off in order to make a predicable progress bar. But in others it might not be. In some tools you may be able to predict if it will happen, and in others maybe not. Another example (from the real world this time): I make a progress bar for an iterative optimization of an design in a program. The number of iterations until the design completes can't be reliably estimated. It's not completely underterministic of course, but the complexity of making that estimation isn't just high, it's likely to be so high that it approaches the complexity of the optimization itself.
- moring 4y ago
  Your second paragraph is basically what I meant: The complexity is just too high. This is especially true when downloading data from the internet is involved. But the first example, git housekeeping, depends only on information readily available locally. git could just give this information to any calling program that needs it, but my guess is that nobody thinks that progress bars are worth it. Actually, in today's world, I'd be happy if progress bars (or even indefinite loading indicators) would even show me when the process has crashed and won't ever finish, but they'll happily show "progress" that will never finish.

by moring 4y ago

alkonaut 4y ago

Let's take another example. E.g. if you have a progress bar for doing a set of 5 git operations you don't know whether the 3rd might start some housekeeping. For some tools (such as git) it might be possible to force this automatic housekeeping off in order to make a predicable progress bar. But in others it might not be. In some tools you may be able to predict if it will happen, and in others maybe not. Another example (from the real world this time): I make a progress bar for an iterative optimization of an design in a program. The number of iterations until the design completes can't be reliably estimated. It's not completely underterministic of course, but the complexity of making that estimation isn't just high, it's likely to be so high that it approaches the complexity of the optimization itself.

moring 4y ago
Your second paragraph is basically what I meant: The complexity is just too high. This is especially true when downloading data from the internet is involved. But the first example, git housekeeping, depends only on information readily available locally. git could just give this information to any calling program that needs it, but my guess is that nobody thinks that progress bars are worth it. Actually, in today's world, I'd be happy if progress bars (or even indefinite loading indicators) would even show me when the process has crashed and won't ever finish, but they'll happily show "progress" that will never finish.