Hacker News Reader

Comment by DanHulton | Hacker News Reader

One way in which it is not simple is that you can't set what the "max" of the bar is and have it auto-calculate the percentage. Like, if I have 7 tasks to accomplish, I have to manually keep track of the percentage to increase it by, and since 7 doesn't increase cleanly, I probably have to custom-code the final update to 100 manually, or it'll be just under or over, depending on how I round. Or maybe I have a variable number of tasks, and instead of increasing by a constant, I have to have separate variables for calculating the amount to increase by.

I know every feature added to something simple adds unforeseen levels of complexity, but this choice doesn't eliminate complexity, it just moves the complexity to calling code, and for nearly every use case.

View on HN

> since 7 doesn't increase cleanly, I probably have to custom-code the final update to 100 manually,

What do you mean with "not cleanly"?

bar.update_smooth(i * 100 / 7)

Once i is 7, this will be equal to 100. No matter your rounding mode. You don't need a CS degree for that formula.

Percentage calculations require multiplying or dividing by 100 in the right places, complicating both the progress bar itself and client code. In typical usage it would be more elegant and more general to have a fraction, x things done out of a total of y, with both x and y updateable.

For example, recursively enumerating the contents a file system interleaves increasing y (when subfolders are visited and unprocessed files and unvisited subfolders are found) with increasing x (when files and folders are processed/visited). At the end x catches up with y.

Lowbar could be easily adapted to a percentage-free style without backwards incompatibilities: the constructor could have a parameter, range with default 100, and new methods update_range() and update_range_smooth() could update y similarly to how update() and update_smooth() update x.

The simplicity of this project isn't really in the usage, but the code base. I guess my main goal was to make a bar that was different from already available loading bars, and give as much control to the user as possible, while keeping the amount of code minimal. Thanks for the feedback though :D

Yes, it's up to you to determine the progression of the program. You can keep track in fractions of 1 with casts and a bit of math.

Perhaps you can use a prediction library such as Prophet (by Facebook) to predict the ETA.

Reply on news.ycombinator.com