On Fri, May 21, 2004 at 07:46:19PM +0100, Bas Scheffers wrote: > Unless you are using low level languages where you have to do your own > memory management, as you described, I don't see a use for it. > > Trust me, if I were doing what you are working on, a debugger would be my > best friends as well. But not using Tcl because there is no good debugger
No, that's not entirely true. And I don't think memory management has much to do with it either. I've never used a debugger with Tcl and have only missed having one on rare occasions, but a good debugger - even a poor one, actually - can be very, very handy, even for quite high level languages. S-Plus and R (both dialects of S) come to mind. S-Plus comes with two different poor-to-mediocre debuggers, I use either one or the other on a fairly regular basis, and I would REALLY miss not having at least the simpler of the two available. What makes you really need or want an interactive debugger? I think the dominant factors are complexity of data structures, and lack of conceptual simplicity/purity and/or power in the language. And perhaps especially any interaction between those two. The more complex your data structures and the more subject they are to nasty edge cases, the more often you'll Really Want to get out the interactive debugger. For example, S is a rather lispy, high-level math/statistics language, and is pretty nice overall. But compared to Tcl, it has more complicated data structures (which is often very handy), and unfortunately, it also has lots of annoying little edge cases and non-orthogonal silliness, usually associated with those data structures. (E.g., selecting 0 rows via subscripting often has entirely different side-effects from subscripting 1 or more rows. Dimnames sometimes magically disappear or become X-prefixed garbage as a side-effect of some other operation. Etc.) You learn to avoid those pitfalls, but it definitely takes longer than with a cleaner language like Tcl (which has fewer and simpler such pitfalls), and some of them still never entirely cease biting you. (Btw, S defintely has some things that I wish Tcl had, like its array/vector orientation and facility with math, but getting into a general language comparison here isn't my main point.) When I use the debugger in S, I'm generally digging around in those more complicated data structures figuring out why they didn't come out the way I wanted. Those annoying little edge cases often have something to do with that - those two aspects definitely interact. And lack of language power sometimes contributes too. E.g., S has very nice table-oriented functionality, but it's facilities for joining tables together in different ways are lower level, less powerful, and more crufty and annoying to use than doing inner and outer joins in SQL, so it's easier to get it wrong, and to not realize that you did until you're staring at the data in the debugger. Yes, C uses manual memory allocation, but what THAT really makes you need is a memory overrun/leak checker like Purify or Valgrind - not so much a debugger per se, I think. You often want a debugger with C code not because of the memory allocation per-se, but because you're building up and manipulating complicated data structures in those bytes that you've malloc. On my last C project, I wasn't really directly manipulating many data structures, and while I did fire up gdb a lot, that was mostly just to see the stack strace! In C you do use the debugger to get the stack trace that from the debugger, but I don't really consider that "using an interactive debugger" proper. So, perhaps the better your language is, and the simpler your data structures are, the less need you will have for an interactive debugger. And that is probably one useful measure of the power and clarity of a programming language, or course. But I don't see the need for debuggers going away entirely anytime soon! :) -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- 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.
