Do I ever agree with this...
Stumbled on this posting by Linus Torvalds. I cannot remember the last time I fired up a debugger to debug a problem. I have demonstrated the debugger for PL/SQL in Jdeveloper/SQL Developer, but I've never used it. I believe the last time I used a debugger for real was in 1992. I gave up, threw it (the debugger) away. It was a multi-threaded Ada application and when run inside the debugger - it would work fine. Outside of the debugger - it would fail. This would happen to single threaded programs too (things just run differently in the artificial environment of the debugger). I made the developer redo their code heavily instrumented - and we solved the insolvable problem in minutes afterwards. I've written about this art of instrumentation many times (here is one). I think this guy is definitely on the right track.
The reason I don't like debuggers in general - I don't think stepping through code a line at a time is a good thing. You are hoping against hope that the problem will just "come out and hit you smack in the face". It is like the difference between touch typing and hunt and peck typing. Using a debugger - you are hunting and pecking. You don't necessarily have a good idea where to look, what to look for - you are just looking for something to "go wrong".
I've said "debuggers are for wimps". In my opinion if you are forced into using one (as a crutch), it probably means you don't have a really good understanding of the code (you might find and fix one bug in the debugger, but miss the 500 other bugs sitting there) and haven't been programming defensively. You become dependent on this debugger thing to find your problems - and when it can't (and they can't many times) you get totally stuck, the problem becomes intractable, insolvable. (this seems to be a major failing with many developers - the inability to perform good problem determination, to create test cases, to whittle the problem back to its bare essentials. It is the single more important skill a developer can have.)
In the 'real code' that I've written (not the quickie demos I do on asktom), literally every other line of developed code is "debug/instrumentation code". I like to say that good developers write two bits of code:
- The code they want to
- The code they have to
But then go a bit further and say that the code they want to write is the defensive code, the instrumentation/trace code. The code they have to write is the code the end user is interested in - to the developer that code that does "file/open" in their application - that is the stuff they had to write. The code before and after the "file/open" bit of code that can be used to diagnose issues, validate return values, validate inputs - double, triple check everything - that is the code they want to write.
The reason they want to write that "debug/instrumentation" code? So they don't have to spend the rest of their natural lives maintaining and debugging their first bit of production code. Which, if they do not make it traceable - they will be.
Once upon a time ago, I wrote a utility called "OWAREPL" - it was the OWA Replacement "cartridge". I wrote it for OWS 2.0 (Oracle Web Server 2.0 - which came right after OIS 1.0 (Oracle Internet Server) and right before OWS 2.1.1, OWAS (Oracle Web Application Server) 3.0, OAS (Oracle Application Server) 4.0 and then AS (just Application Server) now... So, this was about 10 years ago (it later became the foundation for the webdb lightweight listener and then mod_plsql). 50% of this code was debug/trace code - easily, if not more. It was downloaded and used thousands of times. And not once did I have to arrive on site somewhere to debug this code - if something went wrong, I just asked them to turn on tracing for specific modules (a configuration parameter) and send me the trace file. We fixed every problem 100% of the time in this fashion.
Sort of like what happens with Oracle, it is fully instrumented. Have a problem? Get a trace. V$ tables - instrumentation. SQL_TRACE=TRUE, debug/trace stuff.
But anyway - read the rant by Linus - well said.