4 ms·

> But it’s unsatisfying to say “this is false” without explaining why Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a po

> But it’s unsatisfying to say “this is false” without explaining why Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a point out of not backing up any of their claims.

TeMPOraL 7y ago
Is this really a problem? The "falsehood programmers believe" articles I remember reading all list things that were either obvious, or obvious in retrospect.
- deathanatos 7y ago
  I disagree about obvious. Some are not, IMO, obvious, and some are actually true within reasonable bounds. From one of the previous lists[2]: > DST is always an advancement by 1 hour I'd point to this one as not "obvious": it is false. Some extreme northern/southern locations (where the seasonal day lengths get really long/short, since you're so close to the pole) adjust by 2 hours. (E.g., the aptly named Antarctica/Troll[4].) > Months have either 28, 29, 30, or 31 days. > The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities. I usually presume that I'm either a. working in the proleptic Gregorian calendar, b. I am working within a range of time (e.g., company start to foreseeable future) in which the Gregorian calendar is a safe assumption or c. I am working in a situation where I know I'm not working with the Gregorian calendar (e.g., the app/job has specific requirements around, say, a lunar calendar) and I'll know I'm in one of those exceptional case when they apply / the falsehood won't be believed to be false. Within that assumption, that "falsehood" isn't false. It's true: there is no month within the Gregorian calendar that does not have 28, 29, 30, or 31 days. The trouble is the transition onto the calendar. Some languages — in particular, some parts of Java[3] do this — choose a date at which the calendar was adopted and actually expose that in their routines. (But note, however, that the Gregorian calendar was not adopted overnight; it started in 1582 and continued until 1923!) For example, when Great Britain[1] adopted it: > Through enactment of the Calendar (New Style) Act 1750, Great Britain and its colonies (including parts of what is now the United States) adopted the Gregorian calendar in 1752, by which time it was necessary to correct by 11 days. Wednesday, 2 September 1752, was followed by Thursday, 14 September 1752. Again using Java as an example, I believe it chooses the Spanish transition (1582), and since there's a jump there, too, it jumps 11 days, resulting in a very short October, making the two falsehoods listed above actually falsehoods. But just work in the proleptic calendar. IMO, what calendar you're using is effectively part of the datetime type. Having a datetime type that uses multiple calendaring systems is like having a text/string type that also lets you put random bytes in the middle of the string. Of course, the next falsehood was, > There is only one calendar system in use at one time. …which is our stated assumption of "within the Gregorian calendar". So, by definition, this is true! There were a few others, e.g., > Non leap years will never contain a leap day. That are just more fallout. Assumptions need to be stated, and explanations would be more enlightening to the surprised reader. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro... [3]: https://docs.oracle.com/javase/7/docs/api/java/util/GregorianCalendar.html#setGregorianChange(java.util.Date) https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria... [4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
- koala_man 7y ago
  Take the original one about names, which claims that sometimes children don't get names. Should I be flagging mandatory name fields as an I18N concern? How many people are affected? In which regions does this warrant UI hints or changes? Will they have names by the time COPPA stops applying? I've casually Googled this and found nothing, so whatever point the author hoped to make was lost.
- Semiapies 7y ago
  Yes. Only a small minority of Falsehoods articles so much as point people at resources to relevant resources, much less find better practices. Fewer back up their claims. The Falsehoods listicles that were actually obvious were Falsehoods Most Programmers Don't Actually Believe.
- jillesvangurp 7y ago
  The artcicle is confusing unix time, which is an integer that increments every second, with it's UTC representation. This representation is an interpretation of that number. In theory it could be decremented. But this has never happened. In practice what happens is that we add leap seconds, which means that we allow the UTC interpretation of the incrementing integer to have an extra second and not that we move the integer forward by two seconds. The reason that this is not a problem is that most hardware clocks are pretty awful to begin with and need frequent automated corrections (through ntp). This does in fact cause that integer to increment/decrement locally when that happens and far more often than once every few years. This too is mostly a non issue. For practical purposes, time moves forward and when you access time using one of the many high level APIs you get a fresh interpretation of the system clock's integer. A much bigger problem would be the Y2038 problem when that integer overflows. I believe work is underway in the Linux kernel to address that.
duxup 7y ago
I blame (perhaps unfairly) this idea that people write a lot of programming related articles and blogs as resume fodder, and not really for an audience beyond that. I've run across so many "how to do" and it's the same example code and you can see where it has skewed over time... and evolved into something that the author really doesn't understand. Same goes with some of the fundamentals and gee wiz "falsehoods" and such articles. I appreciate the folks taking the time to write it but if they're not going to tell me why: 1.) I don't know if they even know / gave me the right idea. 2.) If I can't grok why then I'm not going to really understand it...
- kosievdmerwe 7y ago
  Talking about resume fodder, my favorite is how everyone seems to have to write an article about bloom filters. Or at least every month or so someone posts an article about them on HN from their blog[1]. They're a brain dead simple data structures and a lot of times the author leaves off the actual hard bit about them: deciding how big they should be and (after reading up about them a bit while writing this comment) how many hash functions they should have. [1] https://hn.algolia.com/?query=bloom%20filters&sort=byDate&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=bloom%20filters&sort=byDate&pr...
Semiapies 7y ago
Yeah, the standard falsehoods listicle would have ended right before that line. Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.
- wglb 7y ago
  As is done in qmail.
  - Semiapies 7y ago
    Interesting—I wondered if anyone was doing that.
waynecochran 7y ago
This is all over dramatized myth busting -- one could simply say they are all true except for the occasional leap second adjustment. No need for the dramatic "they are all false."
- bradknowles 7y ago
  Everything is true, except when it's not. ;)

TeMPOraL 7y ago

Is this really a problem? The "falsehood programmers believe" articles I remember reading all list things that were either obvious, or obvious in retrospect.

deathanatos 7y ago
I disagree about obvious. Some are not, IMO, obvious, and some are actually true within reasonable bounds. From one of the previous lists[2]: > DST is always an advancement by 1 hour I'd point to this one as not "obvious": it is false. Some extreme northern/southern locations (where the seasonal day lengths get really long/short, since you're so close to the pole) adjust by 2 hours. (E.g., the aptly named Antarctica/Troll[4].) > Months have either 28, 29, 30, or 31 days. > The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities. I usually presume that I'm either a. working in the proleptic Gregorian calendar, b. I am working within a range of time (e.g., company start to foreseeable future) in which the Gregorian calendar is a safe assumption or c. I am working in a situation where I know I'm not working with the Gregorian calendar (e.g., the app/job has specific requirements around, say, a lunar calendar) and I'll know I'm in one of those exceptional case when they apply / the falsehood won't be believed to be false. Within that assumption, that "falsehood" isn't false. It's true: there is no month within the Gregorian calendar that does not have 28, 29, 30, or 31 days. The trouble is the transition onto the calendar. Some languages — in particular, some parts of Java[3] do this — choose a date at which the calendar was adopted and actually expose that in their routines. (But note, however, that the Gregorian calendar was not adopted overnight; it started in 1582 and continued until 1923!) For example, when Great Britain[1] adopted it: > Through enactment of the Calendar (New Style) Act 1750, Great Britain and its colonies (including parts of what is now the United States) adopted the Gregorian calendar in 1752, by which time it was necessary to correct by 11 days. Wednesday, 2 September 1752, was followed by Thursday, 14 September 1752. Again using Java as an example, I believe it chooses the Spanish transition (1582), and since there's a jump there, too, it jumps 11 days, resulting in a very short October, making the two falsehoods listed above actually falsehoods. But just work in the proleptic calendar. IMO, what calendar you're using is effectively part of the datetime type. Having a datetime type that uses multiple calendaring systems is like having a text/string type that also lets you put random bytes in the middle of the string. Of course, the next falsehood was, > There is only one calendar system in use at one time. …which is our stated assumption of "within the Gregorian calendar". So, by definition, this is true! There were a few others, e.g., > Non leap years will never contain a leap day. That are just more fallout. Assumptions need to be stated, and explanations would be more enlightening to the surprised reader. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro... [3]: https://docs.oracle.com/javase/7/docs/api/java/util/GregorianCalendar.html#setGregorianChange(java.util.Date) https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria... [4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
koala_man 7y ago
Take the original one about names, which claims that sometimes children don't get names. Should I be flagging mandatory name fields as an I18N concern? How many people are affected? In which regions does this warrant UI hints or changes? Will they have names by the time COPPA stops applying? I've casually Googled this and found nothing, so whatever point the author hoped to make was lost.
Semiapies 7y ago
Yes. Only a small minority of Falsehoods articles so much as point people at resources to relevant resources, much less find better practices. Fewer back up their claims. The Falsehoods listicles that were actually obvious were Falsehoods Most Programmers Don't Actually Believe.
jillesvangurp 7y ago
The artcicle is confusing unix time, which is an integer that increments every second, with it's UTC representation. This representation is an interpretation of that number. In theory it could be decremented. But this has never happened. In practice what happens is that we add leap seconds, which means that we allow the UTC interpretation of the incrementing integer to have an extra second and not that we move the integer forward by two seconds. The reason that this is not a problem is that most hardware clocks are pretty awful to begin with and need frequent automated corrections (through ntp). This does in fact cause that integer to increment/decrement locally when that happens and far more often than once every few years. This too is mostly a non issue. For practical purposes, time moves forward and when you access time using one of the many high level APIs you get a fresh interpretation of the system clock's integer. A much bigger problem would be the Y2038 problem when that integer overflows. I believe work is underway in the Linux kernel to address that.

duxup 7y ago

I blame (perhaps unfairly) this idea that people write a lot of programming related articles and blogs as resume fodder, and not really for an audience beyond that. I've run across so many "how to do" and it's the same example code and you can see where it has skewed over time... and evolved into something that the author really doesn't understand. Same goes with some of the fundamentals and gee wiz "falsehoods" and such articles. I appreciate the folks taking the time to write it but if they're not going to tell me why: 1.) I don't know if they even know / gave me the right idea. 2.) If I can't grok why then I'm not going to really understand it...

kosievdmerwe 7y ago
Talking about resume fodder, my favorite is how everyone seems to have to write an article about bloom filters. Or at least every month or so someone posts an article about them on HN from their blog[1]. They're a brain dead simple data structures and a lot of times the author leaves off the actual hard bit about them: deciding how big they should be and (after reading up about them a bit while writing this comment) how many hash functions they should have. [1] https://hn.algolia.com/?query=bloom%20filters&sort=byDate&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=bloom%20filters&sort=byDate&pr...

Semiapies 7y ago

Yeah, the standard falsehoods listicle would have ended right before that line. Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.

wglb 7y ago
As is done in qmail.
- Semiapies 7y ago
  Interesting—I wondered if anyone was doing that.

waynecochran 7y ago

This is all over dramatized myth busting -- one could simply say they are all true except for the occasional leap second adjustment. No need for the dramatic "they are all false."

bradknowles 7y ago
Everything is true, except when it's not. ;)