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.
