Alex,

Scheme is an imperative language, and anyway I'd like to see my let-bindings when I'm inside a function. I don't believe the claims that Scheme doesn't need a traditional debugger because it is somehow different. It is true that traditional debuggers don't work for Haskell, but they do for Scheme.

I've been programming on and off in Lisp and Scheme for almost 30 years (and yes, i started young!), so I'm not exactly a newbie. What makes me an outsider in this community is that I never got excited about Emacs.

In case anybody is interested, here is a short abstract describing what I'm working on:

Strategic Programming by Model Interpretation and Partial Evaluation

Strategic Programming is a programming paradigm based on factoring programs into general strategies applied to descriptions of particular application requirements. The descriptions are called models, and they generally describe one aspect of an application. Parser generators (like Yacc) are a prototypical example of strategic programming. My talk focuses on defining the semantics of models using interpreters instead of transformations, as in most related work. It is possible to define fully-functional applications by a collection of interrelated models for different aspects of a system, including user interface, security, workflow, data abstraction and persistence. The models may also contain fragments of code written in general-purposes languages. Model interpreters are compiled by partial evaluation. One novelty of this approach is the ability to create data abstractions by model interpretation and compile them by partial evaluation. I will describe my progress in implementing a software development toolset to support strategic programming by model interpretation and partial evaluation. The system is implemented in itself and is targeted at information management applications, including desktop, web and distributed services, although it may be applicable to other domains as well.

William Cook http://www.cs.utexas.edu/users/wcook

...

Yes, that does count as a breakpoint. However, to me the glass is only 10% full, because I can't select a line of code and "put a breakpoint there".

 You are still thinking imperatively (Java, Perl, Python etc.). A 

well-written Scheme program is not a sequence of instructions.

...

I can see that there is a culture clash here. I know I'm representing a view that is a minority on this list. But I'm looking at Scheme from the outside, and this is how it seems to me.

 Maybe when you "get inside" you'll find out that you really don't

need to spend so much time debugging, and the Lisp productivity boost is more than a legend. :-)

Cheers, -alex http://www.ventonegro.org/

I like VI!

No, not really (at least not for programming in Scheme), but I would encourage people to chip in where their interests and abilities lie (and devising/using debuggers in emacs or eclipse or ... is not one of mine, I use the command line with (generate-proper-tail-calls #f)) and to try to avoid arguments about the true nature of Lisp/Scheme, or why Lisp/Scheme is unpopular, or how Lisp/Scheme compares to Haskell or F# or ..., or any of the other regular flamefests on comp.lang.lisp.

By the way, if someone wants to spend the time and energy to submit the gambit programs at

http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/ Programming_language_shootout

to The Computer Language Benchmarks Game (aka the Computer Language Shootout, a name that is met with derision by the current organizer)

http://shootout.alioth.debian.org/

it might improve the reputation of Scheme somewhat. I can help with porting and tuning, but I can't really help with the actual submission.

Brad

2008/9/2 Bradley Lucier lucier@math.purdue.edu

I like VI!

So do I! I use a slightly tuned "limp", which is some kind of LISP mode for vim, which I made a bit more Scheme compliant (needs much more work though).

As far as debugging and GUIs are concerned, I think the following: - since the debugger can be another remote program, writing a GUI for it shouldn't be too hard, should it? - in case of interpreted code, adding/removing "real" breakpoints on instructions should be possible with a JIT and those (ERROR "debug"), but one has to be careful with the semantics of call/cc when code is dynamically changed... (what if you store a continuation containing a breakpoint, and then remove the break and call the continuation? I would expect the breakpoint not to be executed.)

As of Scheme considered "behind", maybe its main drawback is that "apart from scheme interpreters and compilers, no useful application is ever written"... To have scheme used, perhaps we first should have users run Scheme programs... Ruby took off with RoR, since people willing to have a nice dynamic website (and really easily) had to learn basic Ruby. JS, ActionScript and friends are successful because they are often embedded within webbrowsers. We can easily conclude that the success of a language is not its features only, but rather what's written with it that everyone uses... Write a browser, a video player, or a currency converter that people use, and those who like the app and can program will use the language, first to extend the program, then to write their own programs with it... I believe that "pervasive desktop programs" are the best target for any language to take off... Have it included in gnome and ubuntu and voila, everyone will fight to learn Scheme just like python!

One last thing about debugging, even though much of the syntactic sugar (or macros) of CL can be translated into "pure Lisp", I've heard that actually it can (and will) be implemented directly in the target language or VM for better efficiency. Therefor, it can be really better to use LOOP rather than MAP even on lists for the compilation process may generate observationally equivalent code, but with much more optimisations... (and I also believe that listing such programming habits based on Gambit's compilation process could be useful).

P!