portal VS truss

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/

When type checking is needed, I find the Truss library* does the trick quite well.

As for the syntax, there is very little, which can make it a harder lift but once you have the hang of it you won't deal with the issues identified in the parent comment.

* https://github.com/taoensso/truss

I use truss extensively throughout my code to prevent those types of errors.

I haven't tried it myself. I generally just use truss for runtime constraint checking. I use a modified version that integrates scope-capture. And malli validation for more complex cases, but I try to limit that. For me it is better to validate individual attributes as needed, vs validating an entire "type"/collection of attributes. So each function only cares about the attributes that it needs, and validates only as needed.

Use assertions for all data requirements inside functions - I use a modified version of https://github.com/ptaoussanis/truss to ensure that I never get NullReference exceptions, and this also helps make functions more self-documenting. Also use this to assert return data.