Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> 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. I'll try to get more concrete with actual scenarios, but for now it's just a feeling that "it rarely works", e.g. break points don't stop or the code stepped is hardly recognizable. Perhaps Guile aggressively inline things or macros add to the confusion, but that shouldn't be a price the user has to pay for. One of Guile's strong points is supposed to be that it's geared for interactive programming, and I'd categorize stepping code being related to the programming experience being "interactive". > 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? And I've probably countered that before by saying that while it's true that functional programming helps, there are still times where the inputs or the lexical environment I need to understand are complex enough that reproducing them at the global level (REPL) is a pain. Just breaking at the right place and typing ,locals would be a much more efficient way to proceed to see what the environment in scope looks like. > 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. Debugging/live coding abilities do not have to be mutually exclusive. Python excels at both, in my experience. >> 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. Great! -- Thanks, Maxim
