Hi Lee, you made me cry (almost). I've been working in the eighties on Lisp Machine (both Symbolics and Texas Instruments) and I still have to see a programming environment comparable to the one I was using 30 years ago. At the moment we're still far way from those happy days.
Well written! My Best Mimmo On Nov 7, 2013, at 6:32 PM, Lee Spector <lspec...@hampshire.edu> wrote: > > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
