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. Luc > > > I did not say that a debugger was not useful at all, I said that the > > importance of having a > > debugger is *overestimated* especially in an immutable world. > > > > Relying on a debugger as an important tool to support coding is like > > admitting > > the failure of your code before it runs. It's like conceding defeat before > > the fight > > has started. > > > > Trying to a avoid debug sessions as much as possible is more productive. > > Time spent in debug sessions is not spent on more important issues. > > > > Luc P. > > > > > I found this kind of logic hard to swallow. I certainly don't look forward > to creating a lot of bugs so I can get the joy of using a debugger. But > bugs, sometimes very tricky bugs happen, no matter how good your design is. > If you apply the logic that "because we can overuse/over rely on it so it > is better we don't have it at all" we almost don't need anything in the > modern life. Following your logic I would argue that if you don't have an > REPL, it will force you to think hard and write perfect code that does not > need any testing at all. It just runs, because you don't even have a second > chance to know what is going on inside and fix it. The quick REPL loop just > encourage people to write crappy code and constantly tinker with it > (because they know they can easily found out the cause and fix it). Does > that sound right to you? > > We need to get our logic straight before debating this kind of issues. > > -- > -- > 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. > > > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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.
