@chrishowejones tbh, logging statements and trying to keep the code as simple as possible in each function. The only code that I've used regularly that was developed with a debugger was actually quite difficult to use.
and what @kornysietsma said
@kornysietsma I thought part of the joy of Cursive was having a debugger
@otfrom for some folks. I haven't tried it for ages - it used to suffer from the usual problem that debugging functional code is fundamentally ugly - you can hook into procedural bits, but the minute you are inside recur or async code or a macro, the debugger is futile. It may be more awesomer now, but I still tend to feel that debugging is just hard in a language with macros.
still probably be useful in the scenario @chrishowejones describes, trying to hook into a running system and tell what it's doing - as long as your breakpoints are in a fn not in a defroutes :)
So, Emacs folks - I was thinking of doing a clean from-scratch reinstall; my emacs install has gotten dusty and neglected, with hacks I put in over a year ago that I'm hoping are no longer needed. Any pointers for a "good way for a simple emacs/cider setup" circa May 2015? My old .emacs.d/init.el has both marmalade and melpa, for example, I'd hope by now I could use a single package source?
@kornysietsma@otfrom don't get me wrong, I use all the techniques you describe but occasionally I can't reason about what stuff is doing even with logging, etc and I miss not having breakpoints and var inspection. Especially when I think bug is in the middleware, etc. I think the issue is I don't have the time/patience/intelligence to understand in depth what some of these 3rd party libraries are doing for me. That might be a heinous admission but I'm just not that clever and all my brain cells are occupied with business problems ;-)