Clojurians Log v2

🧵

I like the bb error messages for simple typos:

$ bb -e "(+ 1 2"
Message:  EOF while reading, expected ) to match ( at [1,1]
----- Context ------------------------------------------------------------------
1: (+ 1 2
        ^--- EOF while reading, expected ) to match ( at [1,1]

$ clj -e "(+ 1 2"
EOF while reading, starting at line 1

Full report at:
/var/folders/pd/22f

ah yeah, that's from edamame

and this was inspired by work done in clj-kondo actually

Well, but it does the trick for beginners who naturally struggle with parentheses. And that is the point I am making. And making strongly.

yeah I agree that this is very nice addition. also for LLMs

As said, of course with editor integration and clj-kondo the pros have a solution. But what about the poor guy starting off? -> Babashka

What I was referring to earlier were error messages in higher order functions and async usages (nbb). Those are pretty horrible as in: almost no stack trace or location

I hope I can improve those in the future

To that I can just respond with a gut feeling: because bb is an interpreter, I guess bb has a big potential to deliver splendid messages. The main thing is to realise that with bb good messages can be shifted away from relying on a particular editor towards an out of the box experience.

Sci has more potential for better errors than clojure because you get column info. In clj you have to guess this by parsing stacktrace element. There is a proof of concept with scittle (replicant-kanban I think) somewhere in slack with a figwheel like popup but more precise error pointing. I would have to look it up AFC

I also think the stacktraces can be filtered based on the context you are in, because sci is sandboxed and you can use eval safely. So compared to the typical clojure stacktrace you can reduce the noise a lot. In the scittle poc I also created a stepper that uses the code in sci context to go through the code. In clojure this is not possible without going through the class path again (I believe)

Actually I have to correct the last point of loading code, you can and I did that also in clojure, but it is extra work (maybe not relevant)

But the stacktrace filtering is still a USP I think

Maybe I have to explain it with an example. In clojure it might be hard to know where the error occured. E.g. in a web app it can be in library code, somewhere in your ring layer (so anywhere basically). In my experience with Sci you typically have a more isolated use case. So let's in the example of PCP you could filter out the ring stack that comes out of the box with PCP. So you only show the stacktrace of the user code which is typically quite shallow. And because you manage the sandbox yourself you can apply more heuristics e.g. for things like (+ 1 nil) which by default gives a null pointer exception (by heart), but this could be a more meaningful message as well.

@jeroenvandijk thank you for all the concrete clarifications which seem to support my amateur gut feeling. I'd like to emphasise a more mundane point about filtering stack traces. You write > you can and I did that also in clojure I assume this is true. But: what does "you can" mean? What does that "you can" mean for a beginner? I think I know what this "you can" means: Install Java+Clojure+VSCode+Middleware+try-configure-all-this-and-die. When it comes to human readable error messages, I think a "you can in principle" is useless. Those messages need to be within the minimal Clojure-setup to achieve their effect. So I add to your interesting and competent explanations: I think Babashka is the (only?) best place where the standard can be set for Clojure error messages. And then bb's practical-for-average-joe error-detection code can then in a next step partially used as a standard in every editor middleware. I see that path as a way to remove the issue "error messages" out of all the Clojure surveys. And: maybe this error-detection code is already there (?replicant-kanban?). Maybe the effort is really to integrate all this into the standard Babashka binary. In this way those who need it the most actually can profit from it.

@markus.agwin what you could do for a beginner with Sci is creating a custom "clojure" environment (so technically Sci not clojure) setup that gives better errors, smaller stacktraces and other tooling that are possible with Sci. E.g. there was also a talk about using the sandbox functionality in combination with MCP to create a safe execution environment for agents, the same is true for a beginner that might do something wrong in a certain environment I agree with you that a standard can be implemented and could be initiated within babashka or in general as a Sci library since that is the core. I think this is a matter of time. I have some local proof of concepts for this and I'm sure others have worked on this too

Since basic clojure is quite simple with its syntax, when we improve errors and create a safe environment, sci can really make clojure very accessible even to a non-programmet audience I believe

Also another thing to mention is the possibility of making clojure subsets with Sci. E.g. we could decide that loop is advanced and we don't expose it yet. So you can create beginner friendly clojure subsets. Even with an explanation why a user doesn't have access and maybe who does or when they will get it 😎

That onion-type approach with subsets is a neat idea! I'd like to repeat one thing if you forgive me: I think it is important to communicate the name (not SCI but) Babashka in conjunction with error messages. Working merely on an SCI library to then maybe optionally being included in bb/scittle will not set a standard. Such an immense implementation work is a waste of time if it is not guaranteed to land in the binary. A concept must begin with the question "is this sensible within the babashka binary? (e.g would it bloat the binary?)".

If it should be a library or not is maybe a different discussion. I think it would be useful as a library. I can also imagine it will take a while before there is consensus over the form. But either way, babashka can also run sci itself, so with some work you can run babashka in babashka. So you can already create a library with all "improvements" and run it like Babashka. Maybe it can be integrated at some point

i would be very interested in improving SCI’s errors

i do a lot of post processing in flower already but the original message that gets passed to ex-info i use as-is

I found the error stepper demo in Scittle https://clojurians.slack.com/archives/C034FQN490E/p1750177699633579 It doesn't show stacktrace filtering, just stepping through the code. It can be improved a lot, but hopefully shows some potential