I didn't laugh, no. At least not at first, I didn't. It was more a cringe. You're not the first person to assume their problem was with something new or complex and overlooked something simple. I think most programmers can identify with that or will eventually. Always remember it's not always where you expect an error to be that you find it.
In the network administration field, there's an old saying that goes, "physical layer first". You might very well have a corruption in a network stack on some server somewhere, but you'll feel awfully silly if you debug that and find out you just had a bad Ethernet cable. People tend to look for the obvious source of the problem. Sometimes it pays better to look where it's simple to spot a problem even if that's not where you expect to find it.
Update:
Another lesson that "physical layer first" saying tries to teach is that debugging by starting at the lowest level of dependencies and going up the stack from there is quicker than going from the top of the pyramid down. That's not as helpful with software as it might seem, but it is still helpful. Keep in mind, though, that the OS, the OS libraries, and perl have had much more debugging than your code that depends on them. If though, for example, you have your own module and then code on top of it that doesn't behave as you expect, don't be afraid to test and debug your module. Assuming the module works and focusing on the code that uses it can cause one heck of a headache. | [reply] |
This is one of the main reasons why I find ruby impractical. In perl, I can declare lexical variables, they can shadow each other, perl warns if I use a variable name for two things in the same scope (which I often do accidentally as I use lots of one or two letter long names), dies if I don't declare a variable or if I make a typo in a variable name.
| [reply] |