ghostwheel VS scope-capture

big fan of fulcro logic, but isn’t this almost identical to https://github.com/gnl/ghostwheel ?

if all you care about is information / documentation, and maybe validation, then spec or malli are fine. using spec during runtime to simulate a type system is a poor choice in most cases, because you are doing runtime type checking (something akin to dependent types or even esoteric contracts that are hard/impossible to express statically). There are some libs that help bolt a typed facade (using spec) onto the familiar defn / fn, https://github.com/gnl/ghostwheel https://github.com/Provisdom/defn-spec .

Awesome tools.

Personally I can't imagine coding in clojure without scope capture

https://github.com/vvvvalvalval/scope-capture

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 scope-capture to observe the actual data flowing through the system

Scope capture library https://github.com/vvvvalvalval/scope-capture automates this approach.

Is anyone aware of any prior art along the lines of this? I've seen scope-capture but it's more about instrumenting existing programs than writing new ones interactively.

I am not advocating against the use of a compiler. I am going to illustrate how to reproduce the scope of a program and replay it in the REPL as it is done for instance in Clojure with scope-capture. In some use cases, I find this approach is simpler than using a debugger. This approach is possible only because the data is immutable.