Hi, Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
> I also agree! It's hard to convince people to pick Guile for their > project when there is: > > 1. Lack of a debugger that can break and step anywhere in your source > code > 2. Lack of debugger integration to an IDE (it's not even integrated into > Emacs) Well, Guile has a debugger that lets you do that (modulo inlining etc., as with any other compiler), and Geiser is not Visual Studio™ but it does a good job. Also, I think I mentioned before that I almost never use breakpoints on Guile code—not because of some deficiency of the debugger, not (just) because I’m silly or inexperienced, but because it’s rarely the right tool for the job. I believe this is largely due to (1) writing functional code, and (2) doing live programming at the REPL. Why would you use breakpoints when you can just call the relevant procedures on some input to see how they behave? So I think you won’t convince people to pick Guile for their project by selling it as a C/C++/Python drop-in replacement. Guile is about functional programming and live coding so the set of tools differs. > Perhaps we should assemble a Guile debugger workgroup that'd review > what's broken, what's missing, what can be borrowed from other Scheme or > languages for inspiration, and hopefully improve the Guile debugging > experience? :-) Despite what I wrote, I think it’s a good idea. I suppose inspiration would come from other Schemes, in particular Racket, and perhaps from other live-coding systems (Common Lisp, Smalltalk, etc.), rather than from Python or C. Ludo’.
