you use it essentially the same in Clojure that you do in Java - start your repl or application in debug mode, set breakpoints, etc. because Clojure is much more concise, it's not uncommon to see several expressions on the same line if you are stepping (and/or some trickiness with where you hit breakpoints) - it's sometimes helpful to format your code around the area you care about to put expressions on different lines

Thanks for the help, I'm going to try it now

and if it's new code you are writing, then try to structure it in a way, that side-effecting parts of the code are separate from the purely functional parts. that way u can debug the purely functional parts by iterating over them using unit tests.

eg. if u have some api response or db query result, then make a function which produces that result and a separate one which transforms it, so u can test the transforming function without the api or the database.

Yes, I'm learning clojure through advent of code, it's all pure functions in there, it's just that I'm writing a lot of function logic in one function, and sometimes it's not the result I want, and I don't know how to troubleshoot it

The method you provided to isolate the side effects is good, but not the debugging problem I'm currently experiencing, in time it's a pure function, and sometimes when it doesn't match the expected result, it's slow for me to troubleshoot via println

I'm going to do the REPL debugging via https://www.futurile.net/2020/05/16/clojure-observability-and-debugging-tools/ these tools

Perhaps check out Flow Storm debugger, it looks more adapted to Clojure code

@U06S1EJPL just made a self-contained demo about using https://scicloj.github.io/clay/ v2 from Cursive: https://www.youtube.com/watch?v=GsML75MtNXw It explains the main details about the Clay API and configuration and shows how one may publish a blog post using Clay. The API & config of Clay have simplified a lot thanks to Tim's wise ideas, and it is great to have this video explaining some of these ideas.