- CIDER, the de-facto Clojure environment for Emacs, has a debugger[1]. This is also true for some of the larger IDEs, like Cursive.
- Timbre[2] has a number of cool debugging macros, especially spy, which you can tack onto any expression and it'll log it for you. Very useful, similar to the macro in the post, except you don't have to write it :)
I really can't overestimate how valuable a real REPL-driven development environment is.
I find debugging + error messages to be the worst part of Clojure.
In CIDER I have to mark my functions as debuggable before I can step into them - this is an odd requirement and a PITA when the functions are spread out through the codebase. It's so easy to accidentally commit a non-debuggable version as well.
Cursive is a lot better and more modern, with one painful problem: no proper support for 'break on exception'. So on exception the program just closes and I'm just left with a stacktrace in the console. You can turn on 'Java Exceptions', but this has multiple problems:
1. On load of Clojure files there is a ton of Java exceptions thrown, literally making it unusable
2. and if you disable those exceptions in the Condition field the boot up process takes forever to actually run (likely because it's interpreting the Condition field code over and over and over again..).
>In CIDER I have to mark my functions as debuggable before I can step into them - this is an odd requirement and a PITA when the functions are spread out through the codebase. It's so easy to accidentally commit a non-debuggable version as well.
When I'm connected to my repl, I often want to debug things I didn't mark as debuggable (hint: nothing is ever debuggable by default). I can jump to definition, toggle debugging, and then run some code (usually from a comment block or my scratch/user.clj (gets excluded by gitignore)). When I'm done, I can toggle it off or simply re-eval the function. In spacemacs, the normal mode binding for this is
Many times when people complain about Clojure, the solution is "just use already available tool X", but they say "no, I am not used to tool X" and then go to invent some half-baked solution in vanilla REPL. That is great for learning, but spreads lousy (mis)information about Clojure's development process. Folks, learn Emacs + CIDER, or at least Idea + Cursive...
I'm relatively new to Clojure development, but I definitely don't think this is the right attitude if we want Clojure to thrive.
Developers are very opinionated about their choice of tools.
I think our answer to critics on Clojure's debugging workflows who might be using tools that don't have first-class Clojure support shouldn't be to try to convince them to ditch their existing tools and force them to use the few tools that already have first-class support for Clojure debugging. This approach of tying the debugging experience to an editor/IDE only works when your community almost exclusively uses a few de-facto IDEs like in the Java world with Eclipse/IntelliJ and in .NET with Visual Studio. This isn't really the case with Clojure's target audience, who come from all kinds of backgrounds and prefer all kinds of different tools.
Instead, I think our answer should be to try to minimize friction for new developers by allowing them to use whatever tools they prefer and still have access to a first-class Clojure debugging experience, by decoupling debugging from editors and building a standalone debugging tool that can be run without any explicit editor support, but can of course be enhanced by editor integrations (and editors can of course still choose to maintain their own debugging mechanism). This approach would be analogous to the approach taken by the JavaScript community with various browser-based debuggers, and is why we don't hear people complain about the state of JavaScript debugging very often, even though very few editors have built-in JavaScript debugging support.
> works when your community almost exclusively uses a few de-facto IDEs like in the Java world with Eclipse/IntelliJ and in .NET with Visual Studio.
According to the latest official state of Clojure survey, large majority of people use only the few best tools: almost 50% use Cider, close to 30% Cursive, and more than 10% Vim + fireplace. Those are tools that have excellent support for Clojure, including fairly good debugging experience (not sure for Vim though). Those are the de-facto IDEs, with around 90% of the market.
I agree with you: newcomers should be able to start quickly and with as little friction as possible. However, I think that it is easier to choose a well-rounded tool that everyone uses and that is already configured to work with minimum friction and start from that until you build enough skill that you can do better than that, than to insist on the tool that was created for another job and will probably lead from one landmine to another.
I do not insist; if someone disagrees with this, they are in right to do what they think is best for them, but is it Clojure's fault if the path that they chose is not as nice as the paths that 90% Clojurists prefer, especially considering that all these tools are built by volunteers and essentially provided as a gift?
- CIDER, the de-facto Clojure environment for Emacs, has a debugger[1]. This is also true for some of the larger IDEs, like Cursive.
- Timbre[2] has a number of cool debugging macros, especially spy, which you can tack onto any expression and it'll log it for you. Very useful, similar to the macro in the post, except you don't have to write it :)
I really can't overestimate how valuable a real REPL-driven development environment is.
[1]: https://github.com/clojure-emacs/cider/blob/master/doc/debug... [2]: https://github.com/ptaoussanis/timbre