This is a long message because I'm interested in this topic and have been thinking about it. I wish I had more answers and not just questions!
On Fri, Sep 05, 2008 at 09:26:50AM -0500, William Cook wrote:
Resting on laurels!
LISP or you? :)
My question is why Lisp/Scheme seems to be behind *now*, when it should be even farther ahead given the long head-start it had. It may have been true when Peter said it, but that was just at the start of the rise of the scripting languages (Python, etc). Note that Microsoft has had a very reasonable JScript debugger since the late 90's.
I know what you mean, but I want to ask some preliminary questions and then rephrase your original question.
First, can we really compare LISP and Scheme systems to JScript, Ruby, Python, etc.? Ruby and Python are interpreters, with the debugger written partly in Ruby or Python but also using debugging support functions built into the interpreter. For MS's JScript, I would be surprised if the debugger is written in JScript at all. I assume it's written in C, as a separate process that communicates with the JScript interpreter. I don't know about other JScripts/JavaScripts. Some LISPs/Schemes are interpreters but some are native code compilers. That makes the problem of writing a debugger very different than for an interpreter.
Second, should we really combine LISP and Scheme? How do LISP and Scheme differ in their support for debuggers? The Common LISP standard includes an error handling feature but says nothing about interactively watching or controlling another computation (which may be stopped because of an error, or may not). The Scheme standard and SRFIs don't say much about error handling or debugging either. Common LISP includes the idea of restarts, which Scheme doesn't have, as part of the error handling feature. Scheme includes first-class continuations and tail call elimination and other things LISP doesn't have. Is it easier to write a debugger for one language or the other? Is it easier to write a debugger _in_ one languge or the other?
Now... To me debugging is a problem that each implementation solves or ignores on its own. LISP's head start may give new authors ideas, but I don't expect it to guarantee anything. I've seen many LISPs/Schemes whose authors aren't experienced enough to know that a debugger is important, or are experienced but don't believe in interactive debuggers, or seem to have emphasized other features instead of debugging.
Also I don't see how other languages' examples have made LISP worse. LISP is still there, same as before. The other languages have highlighted LISP's stagnation though. So: What can LISP and Scheme authors do to make LISP and Scheme implementations with great debuggers, building on the experience of all previous authors, including the implementors of other langauges?
Although we have many old LISPs to learn from, I haven't seen very much documentation of the underlying principles, algorithms, or design decisions used in those LISPs or their debuggers. I've seen plenty of papers about related topics -- recursion theory, metacircular or reflective interpreters, self-virtualizing CPUs, virtual-machine monitors, machine language or C source debuggers. So I've been eagerly looking for the last step, describing going from theory to application. The lack of papers is definitely part of the problem. Without documentation, implementors tend to copy what they know (what they can see) or reinvent it from scratch.
Maybe you can tell I'm not looking for fancy features and a flashy interface. Instead I would like a solid foundation of support functions and a productive interface. (TTY windows aren't productive but I don't like Emacs either. I haven't found anything I really like, actually.) Also the ability to find and fix bugs, the ability to debug as much of the LISP system as possible, extensibility, speed, good documentation, no bugs in the debugger, and all those other wishes that are hard to get right.
-- Derek