Another thing to remember is that different people have different ways of thinking about things. I work with another programmer who approaches things very practically and incrementally, whereas I think about problems from the big picture down. The methods we use to understand what the code is doing, particularly when some or all of it is written by the other person, may differ greatly in order to support our own modes of operation. Perhaps with something like the Linux kernel the task requires a certain uniformity of mind type in order to contribute efficiently, but in my world of constantly churning out new web applications with a heterogeneous set of programmers, we need tools that fit us, not dogmas about how we should approach problems.
And frankly, test cases only help so much when you're trying to fix something that's broken. They are best suited to preventing you from breaking things as they grow, but if: 1) you're handed something that's already broken, or 2) a change requires touching a lot of pieces at once, the test cases may only tell you something's wrong but not what. The key for any tool is not to try to use it for the wrong jobs. -Titi -----Original Message----- From: Rusty Brooks [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 06, 2006 5:29 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] AOLserver's documentation woes and its future It's funny... I know we're all experienced developers and that therefore all of our viewpoints have validity, but to me debugger > test cases. I am really doubting you are going to have enough test cases to cover all conceivable reasonable inputs. This is not meant to be a barb, but, for example, do you have a test-case that examines what happens if someone ns_returnredirects and then doesn't do an ns_adp_abort before the end of the page? AOLServer contains a programming language and an extensive API, MANY of the commands have unexpected interactions that you don't even know about yet. I learned a valuable lesson a few years ago. A co-worker of mine, whos opinions I did and do respect, held opposite viewpoints as me on some programming concepts. We didn't work together for a few years, and then we did again, and BOTH of us had reversed our opinions and now were equally fervent in the opposite direction. This was enlightening to me, because it revealed that people can hold opposite viewpoints of you and still be right. Yes, I was rather young when this happened ;) Rusty Dossy Shiobara wrote: > On 2006.09.06, Jeff Rogers <[EMAIL PROTECTED]> wrote: >> There are 2 main places where I find a debugger helpful. One is when >> I >> make stupid mistakes (and if you don't occasionally make stupid mistakes >> then I doubt you're actually programming) and the debugger can smack me >> upside the head and point out the stupidity ("Oh, it's a fencepost >> error!"). > > Automated tests should really eliminate this class of bugs, > eliminating the need for the debugger. > >> The other, more important case is when I am digging into code that I >> am not familiar with. > > Again, automated tests provide much more value here than a debugger. > I can look at code, "guess" as to what it's supposed to do, write an > automated test that asserts my understanding, and if it fails, then I > know my understanding was wrong. If it passes, then I understood that > piece correctly. > > The upside here is once I've built up the tests, I can start to make > changes to the code and so long as I don't make any of the previous > tests fail, I know I've preserved the functionality that I've written > tests for. > > Writing the tests once and being able to share and reuse them is worth > much, much more than one throw-away session in a debugger. The tests > will continue to provide value as long as they're relevant. The > session in the debugger only provides the user of the debugger insight > (not the whole team, who could read and run the tests). > >> Linus's rant really rubbed me the wrong way. I thought "considered >> harmful" essays went out of vogue a few decades ago. If you'd rather >> not use a particular tool fine, but don't imply that people who choose >> to use it are somehow inferior. > > I think Linus's rant was on-the-mark: if you feel the need for the > debugger, you're acknowledging a lack of sufficient understanding. > Linus's argument, as I understand it, says that "yes, a debugger is > one way of increasing your understanding, but not the best way, and > definitely not a way I personally intend to support in the Linux > kernel." > >> I thought there was code in AOLserver to support the TclPro debugger >> - >> has that been removed? > > Not that I'm aware of, but it also may not have been used or exercised > in a very long time. Or, if it has, I haven't heard of it. > > -- Dossy > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
