In article <fjmrq5$b9j$1@[EMAIL PROTECTED]
>,
Vesa Karvonen <vesa.karvonen@[EMAIL PROTECTED]
> wrote:
> Rainer Joswig <joswig@[EMAIL PROTECTED]
> wrote:
> > In article <fjmhhd$29k$1@[EMAIL PROTECTED]
>,
> > Vesa Karvonen <vesa.karvonen@[EMAIL PROTECTED]
> wrote:
>
> > > Paul Rubin <http://phr.cx@[EMAIL
PROTECTED]
> wrote:
> > > [...]
>
> Let me just first point out that:
>
> > > 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.
>
> No, that is not true. First of all, I really don't want to see your
> errors. Second, I prefer to see errors in compiler error messages or
> in test case outputs. This way the same error will not be made again.
>
> > Most Lisp environments record source locations. No need for grep.
> [...]
> > 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.
>
> OTOH, if you need to add a feature or fix a bug related to a piece of
> code that doesn't have such a "live" and easily accessible object with
> source locations associated with it then you'll have to find the code
> in some other manner.
Sure, that's constructed. There are enough situations where
the source code is a mouse click away.
> > If I'm interested, I can force the program anytime into the
> > debugger.
>
> Yeah, and you will end up looking at roughly a random location in your
> program. Not very useful, IMHO.
Don't think that it will be at a random location.
>
> > > 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.
>
> Been there, done that. When you start stepping selectively, you are
> talking about at least tens of seconds of time (probably several
> minutes) and in that time one can typically find a place related to a
> feature request faster using other means.
>
> > With a usual Lisp environment you can inspect the stack trace, fix
> > the error and retry or continue - without stopping the program.
>
> I used to program in Visual C++ that implemented a similar feature
> (edit-and-continue) for C and C++. Frankly, I found it to be of very
> limited use (even ignoring the fact that it didn't work very well at
> the time --- I don't expect the Lisp environments to have such
> problems). The main problem is that usually the place where the bug
> is and the place where it is actually noticed are not the same place.
> This is especially the case in statically typed languages, that
> eliminate many trivial "in situ" errors anyway. So, by the time you
> get to the debugger and could fix the bug and continue, it is
> typically difficult to recover the correct result and propagate it
> everywhere where it might have been copied. It is easier to just
> rerun the application.
You might want to try a good Lisp environment (say, LispWorks)
some time.
>
> > > > what's in the data structures, etc.
> > >
> > > Static types make this significantly easier...
>
> > significant easier than what?
>
> Compared to untyped languages, (statically) typed languages make it
> significantly easier to figure out (statically) what kind of data will
> be held in data structures and variables in general.
What is an untyped language? Forth and Assembler. Most other
languages we are talking about are typed. Lisp is typed.
Dynamically typed. Objects carry type information
at runtime. You can point to an object, find its type,
find the definition, find applicable methods and so on.
>
> [...]
> > Yeah, and with an interactive environment you see the real data, too.
>
> Nobody said you couldn't. Who are you arguing with?
You. That's what you don't get when you have no debugger. You
cannot interact with that data. All you see is post-mortem
information.
> > > Debuggers aren't magical. A debugger cannot tell you what the code
is
> > > supposed to do.
>
> > Nobody said that. With who are you argueing?
>
> If you are suggesting that my statement is incorrect, then I guess I'm
> arguing with you.
That's a straw man.
>
> -Vesa Karvonen
--
http://lispm.dyndns.org/
|
