Rainer Joswig <joswig@[EMAIL PROTECTED]
> wrote:
> 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:
> Sure, that's constructed. There are enough situations where
> the source code is a mouse click away.
This point really has nothing to do with debuggers per se. There are
plenty of situations in SML programming where the source is just a
keystroke 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.
I don't just think so in a theoretical sense, because I've actually
witnessed people wasting time like that while trying to debug. Unless
your program is mostly waiting in some kind of select statement or is
basically just a simple loop (or a very small number of such loops),
the speed at which the CPU runs through your code will mean that it is
very difficult to predict where you'll end up when you just enter the
debugger at "any time". This is especially so unless you are already
very intimately familiar with the program. (Of course, statistically
speaking, you'll mostly likely end up in the part of the code that
takes the largest fraction of CPU time in your application at around
the time you enter the debugger.)
But, you can't really believe that a productive way to look for a good
place to start working on a new feature is to run the program and then
enter the debugger at "anytime". Please note that this was the
context of use (adding a new feature) for debuggers mentioned by Paul
in his post that I replied to. Having read Paul's post, I don't think
even his intention was to suggest anything as stupid as that. I think
that what he suggested is that once you have located roughly the
correct spot, you can gain insight into the dynamic semantics of that
part of the program by placing a breakpoint there, running the
program, and then inspecting variables and stepping through the code
after the breakpoint has been hit. I have no objection to that. It
is quite far from entering the debugger at "anytime". However, I
don't think that stepping through the code in such fa****on is the only
or even the most productive way to understand code, which is what I
have been arguing here.
> You might want to try a good Lisp environment (say, LispWorks)
> some time.
Perhaps. At the moment I have no such want.
> > [...] untyped languages [...]
> What is an untyped language?
Some people call them dynamically typed.
> You can point to an object, find its type, find the definition, find
> applicable methods and so on.
What is the type of '(1 "foo" 'bar)? (List isn't it.) But, frankly,
I'm not going to participate in yet another fruitless dynamic vs
static typing argument here.
> > > Yeah, and with an interactive environment you see the real data,
too.
> >
> > Nobody said you couldn't. Who are you arguing with?
> You.
Why? What is there to argue here? I've never said that you couldn't
"see the real data" with "an interactive environment".
> That's what you don't get when you have no debugger.
I use interactive environments daily and have access to several
debuggers. Even one debugger for Standard ML. I just don't find
debuggers all that useful.
> You cannot interact with that data. All you see is post-mortem
> information.
That isn't true even without a debugger.
> > > > 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.
http://en.wikipedia.org/wiki/Straw_man
I assume you are saying that my statement about debuggers is a straw
man. Now, my statement about debuggers is a fact. I haven't claimed
that this would be a position held by anyone. My point is to argue
that debuggers really aren't a panacea or the only way or even the
most effective way to understand large programs that weren't primarily
written by you. I'm arguing that debuggers are not "completely
indispensable" for that purpose as claimed by Paul in his post that I
was replying to.
-Vesa Karvonen
|
