I'd like to chime in here from a background that involved a lot of Common Lisping back in the day.
I have been continually dismayed, as I've moved further from Common Lisp, that debugging facilities that are so basic and ubiquitous and helpful in that world are considered exotic or specialized or necessarily tied to particular IDEs or tool chains in other language ecosystems. Even more basic (and useful, in my experience) than things like steppers or the ability to set break points is the ability just to see the values of locals when an error occurs. This is so obviously useful, and so obviously doable (for decades), that I'm really quite stunned that it's so complicated to do in Clojure and tied to a particular toolset if you can do it at all. In Common Lisp when you hit an error you're thrown into a break loop REPL in which you can view locals, move up and down the stack, and do lots of other fancier things (re-binding things, restarting...) that are probably useful in some situations, but just being able to see the locals is, in my experience, the really huge win. It doesn't matter what IDE you're using or if you're running it from a command line or whatever -- it's part of the language and easy to access no matter how you write and run your code. And my guess is that every Common Lisper takes advantage of this frequently. Different implementations/environments provide different modes of access to this information (e.g. some are GUI-based, and in emacs you can have interactive access to it using interaction conventions that seemed like a good idea in the 1970s :-), but there's always some way to get the information. By contrast in Clojure this information seems really hard to come by. I saw and was excited by a Ritz video -- and I note the enthusiastic applause from the crowd when it was shown that you could see locals (gasp!) -- but my understanding is that this functionality requires commitment to an Emacs-based tool set with all that that implies (which is a lot, IMHO). When I hit an error running my code from "lein run" or from Clooj or from Eclipse/CCW (or I think from any other way that I might run it) I get (or can easily get) a backtrace that shows the function call stack at the time of the error... which is good, but surely (?) the locals are also available when the backtrace is produced and I really also want to see those. The ability to browse and navigate this information dynamically, as in a Common Lisp break loop, is cool but I can understand that something about the Clojure/JVM execution architecture might make that difficult -- maybe that really would have to be tied to a particular IDE? However, if it would just dump all of the values of the locals to standard output, just like it does already with the trace, then I'd be plenty happy since I could dig through that output to find what I need but can't currently get. (Yes, dumping the values of all of the locals might produce a lot of output and yes, one might want to make this an option that could be turned off or on, maybe including options re: limits on how much of sequences to print, etc.) I guess the bottom line of this long message (sorry) is that I hope that some of the great tool developers in this community will continue to consider providing things like debugging tools that are as untethered as possible from particular IDEs. My impression is that nrepl (and maybe other projects) are intended to help "untether" things in this way, but it still seems like a lot of people assume that something like access to locals should naturally be tied to a specific IDE. From my perspective that seems like a really unfortunate assumption. I realize that debugging tools are unlikely to become "part of the language" in Clojure as they are in Common Lisp, but I think there's an important middle ground between that and being available only within some specific IDE. Thanks, -Lee > phillip.l...@newcastle.ac.uk (Phillip Lord) writes: > >> Ritz does some things, but it doesn't do step through like edebug. >> >> I've never found anything as nice as edebug in any language; I guess, >> it's the big advantage of running your editor and whatever you are >> debugging in the environment. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
