When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging
Notes on debugging Clojure code
21–30 of 50 posts
Re: Notes on debugging Clojure code
#22A few more tricks: - 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…
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…
>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
, d bRe: Notes on debugging Clojure code
#23After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about. While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write. I'm afraid this is the point where I should try Haskell, and be unsatisfied…
You should definitely try, even if you end up being somewhat unsatisfied every time you have to use something else.
When I write code in Haskell, it feels right, just like when I discovered Lisp. Only better. And oh, the purity! Not only in the mathematical sense, even the code is completely deprived of clutter.
Re: Notes on debugging Clojure code
#24I fear Lisp had already a better debugging experience in the mid to late 60s...
Could you elaborate on this for newbies like me?
Read this 5-part short series: https://web.archive.org/web/20160304033445/http://malisper.m...
Having compile/break/continue/trace as part of the language standard makes for a nice built-in debugging experience independent of IDE, even if some dev envs are better than others.
Re: Notes on debugging Clojure code
#25When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging I'm struggling to understand this. Why would you ever prefer printf debugging in your local dev environment over using a debugger?
Language and environment independent. It just works. It's like IDEs -- so many people spend so much time writing and learning IDEs specific to a language rather than just picking a standard text editor that can be used for any language on any platform.
Re: Notes on debugging Clojure code
#26Earlier quoted context omitted.
This! 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 t…
> 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?
Re: Notes on debugging Clojure code
#27When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging I'm struggling to understand this. Why would you ever prefer printf debugging in your local dev environment over using a debugger?
Language and environment independent. It just works. It's like IDEs -- so many people spend so much time writing and learning IDEs specific to a language rather than just picking a standard text editor that can be used for any language on any platform.
Yeah this. Does this thing colour parenthesis and stdlib builtins? We're good to go.
Re: Notes on debugging Clojure code
#28After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about. While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write. I'm afraid this is the point where I should try Haskell, and be unsatisfied…
I'm a ruby developer by day and, to me, OCaml-like languages like Elm and F# are better rubies. The language remains as concise and crisp as ruby, the algebraic data types help me more precisely formulate the logic for the app, and the static types remove a whole class of errors and makes refactoring much easier.
As an aside, I have a theory that Elm is a gateway drug to Haskell. Next stop, purescript?
Re: Notes on debugging Clojure code
#29After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about. While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write. I'm afraid this is the point where I should try Haskell, and be unsatisfied…
> While I miss code-is-data very much
FWIW, Elixir has this (and is possibly the only non-homoiconic language to implement "true" macros)
Opt-in typing, though.
Regarding Elm, I love that runtime errors are considered compiler bugs.
Re: Notes on debugging Clojure code
#30Earlier quoted context omitted.
Could you provide links to this better debugger
Found them in other comments, I don't see anything that's native to clojure though, not like pdb is for python at least
Debugging, like most things in clojure, is a library. You can view the implementation (as an nREPL middleware) here[1]. It's possible to use this debug middleware from any random nrepl client, but I'm not aware of any that actually implement a command-line debugger such as you get with python's pdb. I suspect, but don't have any time or inclination to verify, that implementing a basic command-line debugger using this library would be a weekend hack. I suspect this debugger is far more useful integrated into your editor than stand-alone since clojure isn't really a file/line-oriented language (which would make selecting forms hard).
[1] https://github.com/clojure-emacs/cider-nrepl/blob/master/src...