Re: introspection in SML

In article <fjmrq5$b9j$1@xxxxxxxxxxxxxxxxxxxxxxx>,
Vesa Karvonen <vesa.karvonen@xxxxxxxxxxxxxx> wrote:

Rainer Joswig <joswig@xxxxxxx> wrote:
In article <fjmhhd$29k$1@xxxxxxxxxxxxxxxxxxxxxxx>,
Vesa Karvonen <vesa.karvonen@xxxxxxxxxxxxxx> wrote:

Paul Rubin <http://phr.cx@xxxxxxxxxxxxxx> 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/
.

Relevant Pages

  • Re: introspection in SML
    ... I was especially talking about source code when one is using the debugger. ... A dynamically typed languages (Smalltalk, ... Who are you arguing with? ...
    (comp.lang.functional)
  • RE: debugging dynamic code
    ... Cordbg.exe that ships with the framework SDK (including source code I ... the debugger must be inside my app, so iI need to have a debugger that dubug ... depends on how you are referencing your dependant assemblies. ... compile it and debug it. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Open Source Enhancement
    ... I have the capacity to lead ... The entire source code base for OpenBSD is freely available to you and all ... understand programs written in languages that are not familiar to me. ... While OpenBSD is written mostly in the C programming language you are free ...
    (comp.unix.bsd.openbsd.misc)
  • Re: Debugging Newbie Question
    ... The CLR does not understand this source code and so before it ... ASP.NET, however, ASP.NET will compile your page's source code and cache ... the debugger will have IL and x86 created from ... in release mode assemblies. ...
    (microsoft.public.dotnet.faqs)
  • Re: Debugging Newbie Question
    ... The CLR does not understand this source code and so before it ... ASP.NET will compile your page's source code and cache the result ... > does this so that a debugger can attach to the code and allow you to step ... > release mode assemblies. ...
    (microsoft.public.dotnet.faqs)