I’m not a programmer, so my view may be a little bit skewed.. but this seems like a list of things that may or may not be correct (and I’d like to put things in a continuum, or percentages, or some other more practically observable other than a list) but it doesn’t really get any further than that. How substantial many of the claims are?
I honestly doubt “programmers” get all these wrong. I’m not going to link to a post (I’ve seen some people replying with a post as if it’s a substitute for actually saying what’s wrong) or even say that “programmers” is a group too big and perhaps too inclusive to really have anything to say about them. I’ll just link to esr’s guide on hacking and ask the people who wrote the articles who they were dealing with. I doubt that the “hackers” being talked at esr’s guide would do a thing like that. I’d also like to link to the suckless philosophy and ask if the “programmers” and software the writers were dealing with were really what what the suckless philosophy is completely at odds with.
You may be pointing out a problem with English. “Programmers” could simply mean more than one programmer, but there’s an implication that all programmers have those problems or perhaps that the problems are pervasive.
I get the impression that these are mistakes that someone has seen (or made) at least once. Some of them may mostly be made by programmers who are beginners.
I agree that it would be nice to get percentages, even if there are large error bars. I think the main point of these lists is to warn programmers that they may need much more specific knowledge than they think they need. For what it’s worth, the commenters on those lists are programmers, and I’m not seeing comments which say “That never happens!”.
If I ask most programmer or people of other domains whether all months have more than 27 days I think most of them would say, of course all months have more than 27 days. That if wednesday is the second of a month the following friday out to be the 4th of the months.
You actually need to know about the strangeness of september 1752 to know that there this one month in the calender who had less days. It had no days between the 2nd and the 14th.
Children get taught in school that minutes have 60 seconds and not that there a body that decides 18 months in advance whether the minute is supposed to have 59, 60, 61 or 62 seconds.
The september 1752 example sounds like something you’ll find on a trivia show. It’s not really such a good example. It’s the exception rather than the rule. When I read this I feel like I’m back in elementary school being the detail obsessed nerd.
I can’t say anything about the minute example but seeing the trend is to take some obscure occurrence, pointing fingers and saying “how can you not know that?” and looking like a special snowflake to every regular person.
In practical terms, what are the merits of all those examples? Going back to the lists, some of them are probably bad design[1], like one example that a backup is a string of numbers 053901011991.html so let’s not focus on them.
[1] What constitutes “bad design” may vary; some people could probably easily filter through many files like that using ls. Some people prefer minimalism, others don’t feel compelled to use their processing power so sparingly, and would rather get the job done more quickly. (It seems like this has some time implications. If you have cleaner code, you can work with it more easily in the future, if you just want a task done and forget about it) So if I were to describe “bad design” in a way that holds some water, I would say that it hurts productivity.
If you program systems than you get bugs because of corner cases that you don’t anticipate. You need domain knowledge to know all the corner cases.
Actually, the proper solution is to practice defensive programming, not trust the user input, and be generous with sanity checks. Failing gracefully is much easier when your software knows it’s not in Kansas any more.
Which sounds nice right up until a production system shuts itself down gracefully a few hours before a daylights saving time switch purely because of tests which turn out to be more picky than the actual thing they’re supposed to be protecting.
Multi-byte characters can do surprising things to scripts designed to truncate logs written by someone who didn’t take into account the maximum size of characters and chinese production server names.
A lot of a programmers day can end up being related to fixing bugs due to incorrect assumptions or failing to take edge cases into account and knowing lots of edge cases and handling a reasonable portion of them right away is far better than making the most restrictive possible assumptions off the bat.
Sometimes it’s the sanity checks themselves which fail to handle input that the system itself could handle fine.
Do you know that “the system” can handle that input fine? If you do, why did you sanity check reject it?
Sanity checks are just code—you certainly can write bad ones. So?
You don’t want to end up running into the Y2Gay problem
That post argues via mind-numbingly stupid strawmen (or should that be strawschemas?). Yes, you should try to be not stupid, most of the time, to the best of your ability. I agree :-/
This is no different from asking someone the fastest route to get to the store and being told “go a mile down that road and take a left” even though the person didn’t check to see if the road was temporarily blocked. If you ask someone directions, they’re probably not going to add “unless the road isn’t temporarily blocked” and “unless a meteor hit the store last night and I didn’t know about it yet” and “unless there’s a quantum fluctuation that will move all your molecules right next to the store”.
I’ll just link to esr’s guide on hacking and ask the people who wrote the articles who they were dealing with.
Of course not. Many hackers are programmers, few programmers are hackers. People fitting esr’s description are rare and cubicle peons with a keyboard and a screen are legion.
I’m not a programmer, so my view may be a little bit skewed.. but this seems like a list of things that may or may not be correct (and I’d like to put things in a continuum, or percentages, or some other more practically observable other than a list) but it doesn’t really get any further than that. How substantial many of the claims are?
I honestly doubt “programmers” get all these wrong. I’m not going to link to a post (I’ve seen some people replying with a post as if it’s a substitute for actually saying what’s wrong) or even say that “programmers” is a group too big and perhaps too inclusive to really have anything to say about them. I’ll just link to esr’s guide on hacking and ask the people who wrote the articles who they were dealing with. I doubt that the “hackers” being talked at esr’s guide would do a thing like that. I’d also like to link to the suckless philosophy and ask if the “programmers” and software the writers were dealing with were really what what the suckless philosophy is completely at odds with.
You may be pointing out a problem with English. “Programmers” could simply mean more than one programmer, but there’s an implication that all programmers have those problems or perhaps that the problems are pervasive.
I get the impression that these are mistakes that someone has seen (or made) at least once. Some of them may mostly be made by programmers who are beginners.
I agree that it would be nice to get percentages, even if there are large error bars. I think the main point of these lists is to warn programmers that they may need much more specific knowledge than they think they need. For what it’s worth, the commenters on those lists are programmers, and I’m not seeing comments which say “That never happens!”.
If I ask most programmer or people of other domains whether all months have more than 27 days I think most of them would say, of course all months have more than 27 days. That if wednesday is the second of a month the following friday out to be the 4th of the months.
You actually need to know about the strangeness of september 1752 to know that there this one month in the calender who had less days. It had no days between the 2nd and the 14th.
Children get taught in school that minutes have 60 seconds and not that there a body that decides 18 months in advance whether the minute is supposed to have 59, 60, 61 or 62 seconds.
The september 1752 example sounds like something you’ll find on a trivia show. It’s not really such a good example. It’s the exception rather than the rule. When I read this I feel like I’m back in elementary school being the detail obsessed nerd.
I can’t say anything about the minute example but seeing the trend is to take some obscure occurrence, pointing fingers and saying “how can you not know that?” and looking like a special snowflake to every regular person.
In practical terms, what are the merits of all those examples? Going back to the lists, some of them are probably bad design[1], like one example that a backup is a string of numbers 053901011991.html so let’s not focus on them.
[1] What constitutes “bad design” may vary; some people could probably easily filter through many files like that using ls. Some people prefer minimalism, others don’t feel compelled to use their processing power so sparingly, and would rather get the job done more quickly. (It seems like this has some time implications. If you have cleaner code, you can work with it more easily in the future, if you just want a task done and forget about it) So if I were to describe “bad design” in a way that holds some water, I would say that it hurts productivity.
The whole point of the list is that there are exceptions to rules that most people consider to be true in all cases.
If you program systems than you get bugs because of corner cases that you don’t anticipate. You need domain knowledge to know all the corner cases.
Leap seconds manage to crash real world computer systems because their designers didn’t handle them properly.
You don’t want any software that has a calendar to crash simply because a user asks the system to show september 1752.
Actually, the proper solution is to practice defensive programming, not trust the user input, and be generous with sanity checks. Failing gracefully is much easier when your software knows it’s not in Kansas any more.
Which sounds nice right up until a production system shuts itself down gracefully a few hours before a daylights saving time switch purely because of tests which turn out to be more picky than the actual thing they’re supposed to be protecting.
Multi-byte characters can do surprising things to scripts designed to truncate logs written by someone who didn’t take into account the maximum size of characters and chinese production server names.
A lot of a programmers day can end up being related to fixing bugs due to incorrect assumptions or failing to take edge cases into account and knowing lots of edge cases and handling a reasonable portion of them right away is far better than making the most restrictive possible assumptions off the bat.
You don’t want to end up running into the Y2Gay problem: http://qntm.org/gay
Do you know that “the system” can handle that input fine? If you do, why did you sanity check reject it?
Sanity checks are just code—you certainly can write bad ones. So?
That post argues via mind-numbingly stupid strawmen (or should that be strawschemas?). Yes, you should try to be not stupid, most of the time, to the best of your ability. I agree :-/
This is no different from asking someone the fastest route to get to the store and being told “go a mile down that road and take a left” even though the person didn’t check to see if the road was temporarily blocked. If you ask someone directions, they’re probably not going to add “unless the road isn’t temporarily blocked” and “unless a meteor hit the store last night and I didn’t know about it yet” and “unless there’s a quantum fluctuation that will move all your molecules right next to the store”.
In many cases Google Maps has disclaimers like that.
In programming you usually do care more about edge cases then you care in daily life.
Of course not. Many hackers are programmers, few programmers are hackers. People fitting esr’s description are rare and cubicle peons with a keyboard and a screen are legion.