That's not an IDE agnostic approach. IIRC after modifying and reevaluating the function inside which the debugger is currently in, the debug session is terminat

That's not an IDE agnostic approach. IIRC after modifying and reevaluating the function inside which the debugger is currently in, the debug session is terminated and the evaluation context i.e. the values of input parameters are lost. Even if the session can be restored I'm not sure if it survives a REPL restart. And even if it does I'm not sure if it survives a reboot, unlike my approach. Moreover, this approach with defs allows you to inspect every function, even those macro generated. And if committed, such a "debug session" is persistent across every instance where the code is deployed, from any development machine, through all test and staging machines right into production. (So when combined with some remote REPL access... you see what I mean?) Another thing is that I like when my code strongly express the notion of compositionality, i.e. when it looks something like this: (comp ... (partial map ...) foo3 (partial reduce ...) (fn [p] (def s3 p) p) (partial map ...) (fn [p] (def s2 p) p) (partial apply ...) (partial map ...) foo2 (fn [p] (def s1 p) p) foo1 (partial apply ...) (partial map ...)) here I introduce and comment in/out the '(fn [p] ...)' expressions as needed. That kills two birds with one stone. 's1' captures the output of 'foo1' which is also the input of 'foo2' at the same time.