I'm just catching up on this discussion. I think that, regardless of whether any one coder uses them, debuggers are useful to a large subset of people. Even though Clojure likes us to be immutable, there are often times where we would like to debug the mutable parts of our code with something better than a print statement. (Importantly, it's more efficient to identify a problem spot in code if you can dynamically change what you're interested in as you get feedback from a REPL -- this is something print statements can't do. Print statements often have to be brute-force if you aren't exactly sure what to print.)
If we want Clojure to continue to be adopted, we need to support the habits of Web developers. And Web developers expect to: 1. Spot a problem spot in the code 2. Add the word "debugger/debug" at that spot (or make a breakpoint in an IDE) 3. Make the API call/run the spec/refresh the page/click the button 4. Immediately be in a debugger REPL where they can explore the environment While it doesn't solve all problems, and while the more advanced we are, (perhaps) the sooner we can spot errors without a debugger, the fact is that a debugger is part of the standard workflow for many people. The essential thing is that a debugger quickly loads an execution context into your working memory. Instead of having to think about it for a while, you get immediate feedback about what's going wrong (nesting level is too high, that function doesn't return what you think it does, etc) and can jump into a new codebase easily. So both for adoption and for a quick identify-debug-fix cycle (not all of us can afford hammock time for each and every bug that crops up in the code), I think it's important that we start thinking about creating and documenting debugging tools for the community. Tangent: I don't see any documentation for inserting a debug REPL using Ritz. Anyone have any pointers? Does Ritz actually give me what I described earlier? Best, David On Wednesday, May 29, 2013 8:56:08 AM UTC-7, Ben Mabey wrote: > > On Wed May 29 09:18:10 2013, Softaddicts wrote: > > The REPL is a better alternative than a debugger. No REPL available = > increase need for > > a debugger. > > > > If you write creepy code in the REPL, you would do the same in a text > editor and then > > end up debugging it in the debugger... with the old > fail/edit/build/break to point of > > failure cycle. > > > > It's not the same goals and efficiency. Maybe the following will shed > some light. > > > > My REPL's main usage is to tinker with my code in a name space until > it's resilient and > > composable as much as possible. I rarely use the REPL to test short > snippets. > > My code is always backed by the name space I am working with. > > > > I seldom write unit tests. I make use of pre and post conditions as much > as possible > > to knock the rough edges off. > > > > I run integrated tests starting from a root name space (whichever is > appropriate for the > > scope oftest to be done) where I may have to establish some base > context. > > I exercise the code, I can trace/untrace calls, redef fns when needed > and so on without > > restarts. > > > > This insures a minimally resilient code base. > > > > When a severe error occurs, our logging facility dumps also the > environment > > with all the current bindings in scope where the exception was trapped. > > We can log bindings up to the top of the call stack... > > > > This is usable (as clojure maps) to reconstruct the call context and > rerun the > > culprit chunk of code to pinpoint were are the shortcomings that made it > fail. > > When running full integrated tests, we have access to this data. > > > > This is also available from production, we then obtain data to reinject > in dev to > > understand what happened with a limited wiring to establish the global > context. > > We can then reflect this our integrated tests to stress the code. > > > > This is more or less easy depending on the code that failed based on > > how much side effects are impacting the context. > > > > The more you use pure fns, the easier it is to rerun failures from the > appropriate > > call site and fix them. > > The more composable your code is, the less bugs you end up with, fns are > smaller, > > their scope is smaller, ... > > > > When I trigger a debugger it's because I hit a strange error from the > > Clojure compiler that I do not understand upfront or when I deal with > interop code > > and I need to look at the exception and internal states of Java objects > in situ. > > I never need to look at Clojure bindings in the debugger aside from the > obscure > > compilation errors I may hit. > > > > I became much more efficient swapping my time spent in a debugger by > time > > spent in the REPL. This is the bottom line and I am convinced from > comments > > I got from colleagues well versed in the use of debuggers that it's not > a personal and > > unique experience. Everyone of them when they saw what can be done in a > REPL > > were salivating to the idea of tossing debuggers aside. > > > > Yes, but a REPL and a debugger are not mutually exclusive. Nice > debuggers for dynamic languages give you a REPL at breakpoints with all > the context to evaluate expressions against. In other words, why not > have your cake and eat it too? :) Clojure has this somewhat with > nrepl-ritz evaluation commands (I imagine hooking up an actual repl > wouldn't be too hard) and technomany's limit-break[1]. > > I think what this thread has shown is that a subset of the Clojure > community would like better debugger support. Repeated arguments on > why they don't need debugger support isn't constructive since this is > their personal opinion and development preference. I think this thread > has also shown that some people are not aware of the fantastic work > Hugo Duncan and others have done for debuggers in Clojure. To help > with the awareness issue I think having a clojure-docs tutorial[2] on > debugging would go a long ways. As far as getting better support in > general perhaps an ambitious member in the community could start a > kickstarter to help improve the state of affairs. I know my company > would donate to a campaign to improve clojure debuggers. > > -Ben > > 1. https://github.com/technomancy/limit-break (I have never gotten > limit-break to work for me though.) > 2. https://github.com/clojuredocs/cds/issues/27 > -- -- 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.
