We have the foundations
I deserve a better debugger, you deserve a better debugger and once again data is the key.
As I find myself working on different Clojure projects something I notice is Clojure raises the amount of ideas that are practical, projects that would be difficult in other languages are often maintained in Clojure with less code and higher abstractions.
Eric Normand, recently gave a talk at the Heart of Clojure on the subject of abstractions - and if I'm honest with myself, listening to some of the staff of Griffin passionately debate it afterwards I'm not sure I really understood the talk.
But I'm happy to publish wild assumptions - I think when we raise to an abstraction we can advance overall by "travelling down" and making the abstraction real and tangible again, real is hard to define here but I think I know it when I see it.
I think we're on a precipice of personal application debuggers.
We have the data
Earlier this year I gave a short talk about Flowstorm to some internal teams, I would say it went poorly, I got questions not about how to use it rather:
How to use it to monitor a part of the error handling I was not familar with
Nebulus (to me) questions about how it should automatically find problems
After the talk I had a little search in Flowstorm to answer those questions for myself but I know for most people, aren't willing to open up Flowstorm and have a snuffle around in this kind of general UI:
There are many people with a high intolerance to third party tools, if you use the xdebug in the PHP ecosystem you are some what unique, cider debugger/intellij debugger/(anything else) in Clojure.
& I get it - you may already have some ideas on why tools are important/unimportant to you.
Something overlooked by me in my own talk is probably the most important aspect of Flowstorm it's this API:
It's the data Flowstorm collected along the way and it's beautiful - it's right there if I ask for it:
All the data that ever flowed in my program's runtime, with the right code I could ask anything.
We have the UI
In the spirit of quick iteration I booted up Clerk into the project:
and went to town, some functions to identify nrepl threads so I can pass the thread ids into get-timeline and soon my flowstorm timelines were coming back to me as data:
xxxxxxxxxx(require '[flow-storm.runtime.indexes.api :as ia])
(def timeline (ia/get-timeline (nrepl-thread-ids)))
Something I should say is the Flowstorm documentation on programmable debugging is a little light on the ground but I have personally asked questions #flow-storm on the Clojurian's Slack and the maintainer is lovely and super helpful, he has sponsors enabled on Github do check him out: https://github.com/jpmonettas.
So far Clerk is amazing as a tool of exploration and I feel like I've literally just begun.
I want to publish my plan ahead of time to spread the idea.
We will have the interactivity
Clerk has a few drawbacks for my use case, if my timeline gets appended to in Flowstorm I won't see those changes straight away, only if I add some more code/reload/button press my watched notebook and I can't truly filter the data, that could be worked around but more fundermentally there is a design opinion in Clerk where it is essentially a viewer, it's not a complete web application in of itself, so if I wanted a seperate page for a seperate part of my code that's not really Clerk's wheelhouse.
I don't think I can give it to others on the team, as a Clerk notebook because it would involve them changing vars manually but perhaps it will be just far enough?
I will keep Clerk as my internal scratch space for my debugger, but I really want the scope to be able to completely re-implement the UI of Flowstorm in a way that makes sense for the applications I work on using Clojure Electric.
If you have not already check out their V3 video:
Clojure Electric promises to be an outstanding abstraction for highly interactive internal apps.
I suspect Clojure Electric will take me close to my cognitive limits, particularly because I think I will need to make use of its substrate, Missionary, and Electric itself will not be introspectable in nearly the same way most of my applications currently are.
I don't know what it will take to bring Clojure Electric back to ground in terms of abstraction.
But all the workable puzzle pieces are here for now, and maybe soon we'll have one more:
Will we have what we deserve?
Sunday 29th September 2024
Written but not thoroughly read by Adrian Smith
In the ethos of "What it means to be open"