3 ms·

I see absolutely nothing wrong with this. It replaces a slow way to write human-readable intervals with a fast way. How is that a bad thing?

by jfager 15y ago

LoonyPandora 15y ago
Because it is wrong. Time is a difficult problem to solve, it doesn't move at a constant rate, the length of days and years change. You simply cannot set a constant and have it be "correct". It may be more performant to set time ranges as constants, but you will get in to trouble unless you know exactly what you are doing. The people at Twitter who wrote the code will be aware of the trade-offs they have made, but what happens when Jo Random developer forks it on GitHub without thinking it through because "it's fast and Twitter use it - it must be good!" For example: T_1_MONTH = 2592000 Not all months have 30 days. T_1_SOLAR_YEAR = 31558150 A solar year, is (roughly) 31556925.25218 seconds[1]. [1]http://www.wolframalpha.com/input/?i=seconds+in+a+solar+year http://www.wolframalpha.com/input/?i=seconds+in+a+solar+year
- jfager 15y ago
  Just by the mere fact that these are constants documented to be in seconds, it's clear that they shouldn't be used for sensitive or precise time calculations. If you're at the point where you don't realize this, you probably aren't going to be able to use a full-featured time library correctly, either. "Difficult for novices to use incorrectly" is a good feature for code to have, but it's not the highest good, and its absence does not mean that the code is bad.
snprbob86 15y ago
How many time constants could possibly be in their code base? A few dozen? Instead of writing `foo(3.days)` they are writing `foo(T_3_DAYS)` with this library. Instead, why not just create a constant `BAR_DURATION = 3.days.in_seconds` and then write `foo(BAR_DURATION)`. Problem solved.
- jfager 15y ago
  You can still assign these values to semantically-named variables where appropriate, with the bonus of not having to monkey-patch ints just to define a few dozen constants. It's benign, boring utility code, I just don't get what's offensive about it.

I see absolutely nothing wrong with this. It replaces a slow way to write human-readable intervals with a fast way. How is that a bad thing?

by jfager 15y ago

I see absolutely nothing wrong with this. It replaces a slow way to write human-readable intervals with a fast way. How is that a bad thing?

LoonyPandora 15y ago

Because it is wrong. Time is a difficult problem to solve, it doesn't move at a constant rate, the length of days and years change. You simply cannot set a constant and have it be "correct". It may be more performant to set time ranges as constants, but you will get in to trouble unless you know exactly what you are doing. The people at Twitter who wrote the code will be aware of the trade-offs they have made, but what happens when Jo Random developer forks it on GitHub without thinking it through because "it's fast and Twitter use it - it must be good!" For example: T_1_MONTH = 2592000 Not all months have 30 days. T_1_SOLAR_YEAR = 31558150 A solar year, is (roughly) 31556925.25218 seconds[1]. [1]http://www.wolframalpha.com/input/?i=seconds+in+a+solar+year http://www.wolframalpha.com/input/?i=seconds+in+a+solar+year

jfager 15y ago
Just by the mere fact that these are constants documented to be in seconds, it's clear that they shouldn't be used for sensitive or precise time calculations. If you're at the point where you don't realize this, you probably aren't going to be able to use a full-featured time library correctly, either. "Difficult for novices to use incorrectly" is a good feature for code to have, but it's not the highest good, and its absence does not mean that the code is bad.

snprbob86 15y ago

How many time constants could possibly be in their code base? A few dozen? Instead of writing `foo(3.days)` they are writing `foo(T_3_DAYS)` with this library. Instead, why not just create a constant `BAR_DURATION = 3.days.in_seconds` and then write `foo(BAR_DURATION)`. Problem solved.

jfager 15y ago
You can still assign these values to semantically-named variables where appropriate, with the bonus of not having to monkey-patch ints just to define a few dozen constants. It's benign, boring utility code, I just don't get what's offensive about it.