flow-storm-debugger VS portal

Tracing debuggers give you the best of both worlds. I've recently started using Flow-storm [0], by @jpmonettas), and it's been quite transformative. You can still easily see the values flowing through your system (better than just "prints"), and it can handle multi-threaded / async scenarios quite nicely. You don't need to manually step through code, you can just "see" your data flow, and when you have loops or some other form of iteration, you can see the data for each pass. Coupling this with a good data visualization tool (such as Portal [1]) really feels like magic. I've been doing Clojure for quite a few years now, and was very happy with my plain REPL-driven workflow, but this is way better.

[0] https://github.com/jpmonettas/flow-storm-debugger

[1] https://github.com/djblue/portal

This is another example, a tracing time travel debugger for Clojure https://github.com/jpmonettas/flow-storm-debugger

Supports a bunch of stuff described there and more.

Lisps have some good tooling around debugging, for example clojure's flowstorm or common lisp which has built into the language most of what this article is talking about.

There's some good debugging tooling for Clojure as well. A recent entrant is https://github.com/jpmonettas/flow-storm-debugger and of course there's the estabilished pretty full featured debugging features in CIDER (Emacs), Calva (VS Code) and Cursive (IntelliJ). And for barebones tracing from REPL there's goo old clojure.tools.trace.

For Emacs there is something already if you use the Emacs integration described here https://github.com/jpmonettas/flow-storm-debugger/tree/flow-docs/editors.

Tracing debuggers give you the best of both worlds. I've recently started using Flow-storm [0], by @jpmonettas), and it's been quite transformative. You can still easily see the values flowing through your system (better than just "prints"), and it can handle multi-threaded / async scenarios quite nicely. You don't need to manually step through code, you can just "see" your data flow, and when you have loops or some other form of iteration, you can see the data for each pass. Coupling this with a good data visualization tool (such as Portal [1]) really feels like magic. I've been doing Clojure for quite a few years now, and was very happy with my plain REPL-driven workflow, but this is way better.

[0] https://github.com/jpmonettas/flow-storm-debugger

[1] https://github.com/djblue/portal

In this meeting, Lukas Domagala of the Calva team and Chris Badahdah, Portal's creator, presented Calva Notebooks, their integration with Portal, and other Portal updates.

Also my dot-clojure and vscode-calva-setup repos have some interesting stuff in for using/customizing Portal for use with VS Code: * https://github.com/seancorfield/dot-clojure * https://github.com/seancorfield/vscode-calva-setup * https://github.com/djblue/portal

One thing that really helps with debugging is learning to use tap>. Even after a decade of using Clojure, I found it game changing. I personally use it with djblue/portal, which has a lot of bells and whistles, but isn't too hard to get going with the basics. You don't need an UI for tap>, though, if you don't want it.

You may want to try using tap> for debugging, which avoids this problem and is generally more convenient in my experience. I use it to log values with either an atom or Portal.

Portal makes deving so much easier! Having your tapped data available to inspect and transform in the Portal UI is much easier, cleaner, and faster than in the REPL/output window.

Clay is an attempt to create compatibility across data science notebook plugin scripts. Today, Clojure's data viz tools (e.g. Clerk, djbue/Portal) offer similar abstractions for scientists to 1) create notebook documents and 2) enable dynamic exploration of data. These tools all work by attaching rendering metadata to values. But the render code is not portable across tools, which means a script written for one tool is not compatible with all the others, and this inhibits scientific work and makes the toolchain inaccessible to scientists who don't know Clojure.

tag / stick into something like https://github.com/djblue/portal makes this problem instantly go away, and I get a whole bunch extra stuff at the same time: https://www.youtube.com/watch?v=gIoadGfm5T8 If you MUST have it codified somewhere, probably the next highest leverage point is to use specs. Typically we do this when you've a single set of data structures that are widely reused (as opposed to, say, a map that's only used between a single SPA component and an API call). I've tried both clojure.spec and Malli. Clojure's spec is satisfactory. Malli's ergonomics and performance are fantastic. https://github.com/metosin/malli

;; :main-opts ["-m" "cognitect.rebl"]}

Into your '~/.clojure/deps.edn'.

From there I can just add 'rebl' as a profile to my Intellj when you start a REPL it starts automatically.

There are also alternative tools like Portal to do the same things: https://github.com/djblue/portal

Or: https://vlaaad.github.io/reveal/