In article <fjmhhd$29k$1@[EMAIL PROTECTED]
>,
Vesa Karvonen <vesa.karvonen@[EMAIL PROTECTED]
> wrote:
> Paul Rubin <http://phr.cx@[EMAIL
PROTECTED]
> wrote:
> [...]
> > That snipped an im****tant part of Michele's reason for liking
debuggers:
>
> > When I was mostly working with code written by myself, using
> > incremental development I did not feel the need for a debugger;
> > however once I started using large frameworks I found out the
> > debugger to be invaluable as an exploratory tool, to see exactly
> > what was happening under the carpet in framework code.
>
> Note that I'm not arguing that debuggers wouldn't be useful. My point
> is that it is typically more productive (in the long run) to avoid
> using debuggers and instead invest on types, tests, assertions,
> logging, etc... These are things that can (and usually do) make it
> easier to work with the program over time.
When I see an 'error', you want to see it directly in the program.
All the other stuff is some kind of pre- or post-mortem
analysis.
>
> > I find them completely indispensable for that purpose as well. It's
> > extremely common to have to dive into a large unfamiliar program in
> > order to add a feature (not necessarily fix a bug).
>
> Yes, I know from experience (of both adding features and fixing bugs).
>
> > In order to add the feature you have to find the part of the code that
> > has to do with youe functionality
>
> In my experience, typically the fastest way to find a good place to
start
> looking at the code is to use grep --- not a debugger.
Most Lisp environments record source locations. No need for grep.
> For example, if
> the program has a GUI, you just grep for labels you can see in the
> relevant widgets.
If you'd use, say, LispWorks, you directly inspect windows and
their contents. From there you get to source code or
you can invoke functions on the objects from the REPL.
> If the program outputs a log, you can grep for log
> messages. If the program produces some other kind of output, you grep
for
> matches from that output. Usually it takes but a few seconds to find a
> good place to start looking at the code.
>
> Debuggers become (really) useful only after you know a good place for a
> breakpoint.
If I'm interested, I can force the program anytime
into the debugger.
> A good place for a breakpoint is (very) near, just before,
> the place you ultimately want to look at. Before you know such a good
> place for a breakpoint, the debugger is typically mostly useless in a
> large program, because it is typically prohibitively time consuming to
> (single) step through the execution of a large program.
That's why you step selectively.
> > and have an understanding of what the program actually does in order
to
> > get there,
>
> For this a good log can be very useful. In the absence of a good log,
you
> might be able to get an execution trace automatically with a relatively
> small effort.
>
> A useful "static" technique for getting a "big picture" of a large
program
> is to print out a dependency graph.
>
> If you are fixing a bug, then in most cases with SML, you should be
> getting an exception. With SML/MLton, you can easily get the exception
> history (stack trace) in such a case and that usually gets you very
close
> to the problem.
With a usual Lisp environment you can inspect the stack trace,
fix the error and retry or continue - without stopping the program.
> > what's in the data structures, etc.
>
> Static types make this significantly easier...
significant easier than what?
> > It's FAR easier to do that by running the program under a debugger,
> > poking around to see what it's doing, what kinds of args get passed,
> > etc., than to either stare at the code statically
>
> ...With MLton compiled programs, for example, I can nowadays just place
> the cursor on a variable and see the type of that variable, which
> typically gives a good idea of what kind of data actually gets passed.
> With MLton compiled programs, one can also easily jump through all the
> uses and the definition of any binding, which typically gives you a good
> idea of what the purpose of a particular variable, parameter, or
function
> is, for example.
Yeah, and with an interactive environment you see the real data, too.
> > or go through a million compile-and-trace cycles adding and removing
> > print statements.
>
> But that would be silly. Instead of adding and removing print
> statements, you should create (or just use --- it probably already
> exists for your language) a simple logging facility (roughly a page of
> code) that lets you add concise logging statements to your code and
> leave them there without harm. Furthermore, whenever you learn a key
> invariant that might be violated by the program, you should add an
> assertion to the program to check the invariant or change the program
> to enforce the invariant through static types.
>
> Again, compared to using a debugger, if you do this well, this has the
> benefit that your program becomes easier to maintain over time.
This is orthogonal to using a debugger.
> > Maybe test driven development works ok for writing new code when you
> > keep the whole design in your head as you develop. For the far more
> > common task of maintaining legacy code, debuggers (for me anyway) are
> > almost impossible to live without.
>
> Does the legacy code you are maintaining come with a useful test
> suite? Does it make good use of a logging facility? Is it written in
> a safe statically typed language? Does the code use assertions to
> enforce invariants that are not enforced by static types? Can you see
> the exact types of variables in your IDE? Can you trivially and
> accurately browse through all uses of any binding? Can you get data
> such as call graphs and stack traces from your program? Can you get a
> dependency graph from your program? Is the program mostly written
> avoiding side-effects? Does the language make it easy to avoid using
> mutable data structures?
>
> It is easy to use legacy code as an excuse. It is that badly written
code
> that nobody wants to touch or even to look at. Justifying the use of
> wasteful programming practices using "legacy code" as an argument is a
> mistake. If you can't make sense out of code without a debugger, the
> problem is with the code. Fix the code or find another job if you are
not
> allowed to fix it.
>
> In my experience, debuggers also don't get you very far when you are
> working with non-trivial algorithms and data structures. Then you
> really need to understand the algorithms, data structures, their
> invariants and variants, because extrapolating such information from
> particular runs is typically extremely difficult. In the worse case
> you just keep on "fixing" symptoms, probably even breaking the code
> yourself, because you don't actually understand the program.
>
> Debuggers aren't magical. A debugger cannot tell you what the code is
> supposed to do.
Nobody said that. With who are you argueing?
> At most they can show you what the program does at
> run-time.
Well, that's something which static analysis does not provide.
> I say "at most", because there are programs that can be
> difficult to run productively under a debugger
> (e.g. concurrent/parallel programs, interactive real-time programs
> (e.g. games)) --- especially unless you already *exactly* know where
> to put the breakpoint (if you don't put the breakpoint at the right
> place, you'll only make it next to impossible to run the program).
>
> -Vesa Karvonen
You might want sometime to catch up with the Smalltalk 80 environment.
--
http://lispm.dyndns.org/
|
