Omnimaga
General Discussion => Other Discussions => Miscellaneous => Topic started by: AngelFish on September 01, 2011, 10:35:13 pm
-
One thing I've noticed from a lot of people is the assumption that the tools they use are at fault for the errors they observe. While this can indeed be the case (one only has to look at the bugs list of any major project for evidence), the first, second, and third rules of debugging are to assume that the tools are perfect until all other possibilities are disproven as the source(s) of the error(s). One example relevant to the TI is that of OS v. 2.5x, an OS often cited as the cause of many inexplicable errors. However, it is well known that the vast majority of errors are user errors, not code errors, especially in any prominent piece of code. As comfortable as it is to blame the tools, those same tools are debugged very thoroughly for the simple reason that bugs are often far more important in a tool than in a random program. In general, important programs such as Operating Systems, Compilers and Interpreters1 are among the least buggy programs available by sheer necessity. Before claiming an error is caused by any of the above, please stop and consider whether the errors are valid bugs. Spend time looking at the documentation. Check previous bug reports and your own code carefully. Major bugs in tools are extremely rare, highly publicized, and almost always well documented.
1: There is almost never a good reason to assume a hardware bug in commercial hardware. Don't do it without extremely strong evidence to back that claim (such as integer addition of 1 and 1 producing 3, in which case you should still be checking your display and register loading routines first).
-
Well I assume this excludes TASM, right? I remember TASM did stuff like throwing an error about a missing End even if it was present. :P
Also same for Axe which still has bugs if I remember, although I guess it's best to check your code first before reporting a bug.
-
SDCC, in the 3.0.0 version and in the optralloc branch, defies that statement by making up opcodes, using a jr when it is clearly trying to jump by a 16 bit number, or just failing to manage the stack... But that's just me and mah buggy OS, which somehow runs.
-
"Compilers are mostly right" just didn't have the same ring to it :P
-
Most of the time, the compiler is often the reference implementation of a language. So it's right because the author decided it.
-
I have to admit, it was always tempting to blame the language when my hello world programs wouldn't compile, when I started programming C years ago. Hey, it was a long time ago :P
If I hate some layout of a lang, often there's a way around it, like writing my own lib around it that avoids the issue from then on :P
This topic really doesn't apply to early community projects, or homemade ones, though. For commercial ones it almost surely does.