Clojurians Log v2

for clerk, choosing sci over regular clojurescript allowed for a better ux than both the jvm cljs compiler or the self-hosted one. With the jvm compiler, I’d have slow initial compile times and a stateful watcher and the complexity of dealing with optimizations (simple vs advanced) on deploy. With the self-hosted compiler, I’d get a very large and slow to load bundle. I feel like sci was a great fit here for clerk, it’s advanced compiled so reasonably sized while still allowing to add interpreted code (which I couldn’t do with an advanced compiled closed world cljs aritfact). Also clerk typically isn’t a use case where the peak perf of normal cljs brings much benefits and I’m in control of what parts are part of the compiled bundle.

two other benefits of sci over jvm cljs I saw for clerk: 1. the compiler/interpreter not running out of process (in the jvm) making the repl setup less brittle 2. fewer potential depedency conflicts when using clerk as a library between clerk’s and the user’s cljs compiler or shadow-cljs versions

The SCI sandbox is very important for a dataviz tool I’m building

interesting!

cc @mkvlr @djblue @daslu

It seems the SCI + CLJS usage falls into three groups: • Playgrounds • Data viz "scripting" • Node or browser scripting (Joyride, nbb, scittle)

Hi! These make sense to me as the main use cases. Of course, these groups have been used for teaching, science, etc. Most recently, you can see some examples in recent #civitas posts, e.g., by @timothypratley and @markus.agwin. I think scittle is very useful for prototyping clojurescript apps, that may then later be deployed with actual clojurescript compilation. There have been some discussions/hopes to use it for data processing / data analytics, e.g., in combination with https://github.com/cnuernber/tmdjs. I don't know of any available example, but I think we can create a proof-of-concept if you find it useful.

👍 When adopting scittle or SCI had you considered any alternatives - why did you choose this?

I used it because it was easy. E.g., no build process was needed, as long as the relevant modules (scittle reagent, etc.) already existed. It reminded me of a similar experience that I had with #klipse a few years earlier. Eventually, a lot of the code that was prototyped with Scittle (e.g., the way Clay renders builtin visualization kinds) has been replaced with plain Javascript calls to the relevant data visualization libraries. Still, Scittle is useful in the user-side of Clay for easily creating visual and interactive outputs without leaving the regular Clojure namespace and without needing to know anything about clojurescript build processes. The recent examples at #civitas demonstrate that.

Thanks. "Easy" surely seems a common reason why people adopt certain tools :)

i don’t use CLJS, but it may interest you to know that SCI and Graal were the main reasons i picked Clojure for my project in the first place The only other language I know where it’s easy to embed an sandboxed interpreter for the same language with near-native startup times is Forth (and maybe TCL?), and Forth was not a good match for my problem

if you relax the “sandboxed” constraint you can add in Julia but Julia was still not a good fit because it’s line-oriented

https://codeberg.org/jyn514/flower#why-clojure

Scittle 🎳 is wonderful because it works (reliable/stable), zero build/setup (perfect for including in blog posts or ideas), hot reloads are hotter (faster than cljs dev recompile time), and it's more flexible (can embed the code in HTML, or have a cljs file, or several cljs files). I've used all the alternatives 🧹 and am certain that Scittle is the best choice for most situations 🚀 I particularly enjoy using Scittle and Clay together as a REPL experience that embraces the browser in a direct and obvious way.

> hot reloads are hotter how do you hot-reload?

I personally use Clay - whenever I change a CLJS file, it sends it to Scittle. There is also cljs-josh

@timothypratley where I can read about how this works?

Clay has a feature called https://scicloj.github.io/clay/#live-reload which watches for file changes; Clojure namespaces are evaluated to make a HTML file that is reloaded, when a CLJS file is modified, it https://github.com/scicloj/clay/blob/c4fa35c11034614d42c48c1223d8767267cad385/src/scicloj/clay/v2/live_reload.clj#L74 the file in the browser by sending a websocket message to the page. There is a brief description (embedded in a larger post) https://clojurecivitas.github.io/instaparse/grammar_of_physics/rigid_body.html#the-laboratory in the #laboratory section of "A Grammar of Physics". Activating Clay "live-reload" in VSCode or IntelliJ can be done by invoking the "Clay Watch" command, or if you prefer using the REPL: (scicloj.clay.v2.snippets/watch {}) The easiest way to experience it is to clone https://github.com/ClojureCivitas/clojurecivitas.github.io and open one of the notebooks like src/instaparse/grammar_of_physics/rigid_body.clj or just have clay on the classpath.

I'd like to muse on: Scittle is > reasonably sized while still allowing to add interpreted code (which I couldn’t do with an advanced compiled closed world cljs aritfact) By extension: this "allowing to add" means that with Scittle, there is no option but to publish code that is Clojure syntax. While Cljs/Cherry/Squint are meant to (and will practically always) be used to eventually get rid of Clojure, with Scittle one cannot help but creating Clojure code that shares itself. meme (/miːm/ ⓘ; MEEM): an idea, behavior, or style that spreads by means of imitation To put it another way: because of being an interpreter, SCI is closer to the original idea of Lisp than compiled Clojure. While that has drawbacks, that means that Scittle is the only Clojure tool that automatically creates Lisp memes.

do you mean, you can't spit out generated JS and then leave Lisp behind? I think I can make a version of scittle that works with cherry instead and does the same thing, but uses runtime / in memory compiled code instead (been on my mind a long time, but never go around to it yet)

Yes, that is what I mean, one cannot spit JS using current Scittle. Now about a future "Cherrittle" (can't have "Sci" in its name). This idea naturally comes to mind. And I gave it some thought as well. I simply to not know whether that is a better idea than current Scittle. As said, an interpreter is closer to the original Lisp idea but also has drawbacks. I never came to a conclusion for this idea. I like Scittle. Cool would be a Scittle that is compiled with Cherry, because then one could extend a particular Scittle version with Cherry compiled Clojure. Also, Scittle core could then be declared as "System library" in the GPL sense. On the other hand, a project like Scittle-kitchen has lots of Cljs compiled libraries in it, maybe its best to leave Scittle compiled with Cljs.

yeah. I would go with cherittle (or whatever) just for performance reasons probably. perhaps bundle size would also decrease, but not dramatically

I like current Scittle/SCI because of its stable Nrepl. Without being competent in any way, I guess with a "cherittle" and its "runtime compiled" JS that would be hard to imitate, right? At least lots of testing would be needed, I guess?? Also I like the error messages of Scittle/SCI. (Actually, I do not know why people still bring up "error messages" up in surveys. Just use babashka if you are a beginner who does not want to read JAVA stacktraces.) I guess a "cherittle" could not have those good messages. I still like the idea of having a Scittle/SCI consisting of js-files that are not made with Shadow-Cljs but Cherry. I cannot say exactly why I like that idea really. Maybe its total nonsense.

I think error messages could actually get better with cherry. in nbb error messages are often not that good due to async code being involved. this is one of the things I'd like to improve in SCI and I have some ideas for it. But with cherry you could use source maps

Well, the prospect of splendid error messages are always a good argument for any new Clojure interpreter/compiler. But beyond such a very general and remark (i.e. platitude), I really have to pass here.

I'm glad that you experience error messages in bb / SCI / scittle as good though. I often feel it could be better when I try to debug stuff

Babashka gives good messages for stupid typos. My opinion is that human readable error messages are important for beginners (who do stupid typos). And also important for people who are not software developers but "Scriptors" like me. In that sense I like the error messages of bb. And I fully understand that hard-nosed developers prefer the Java Stacktrace. But what I see in SCI is that because it is an interpreter, the possibilities for really splendid error messages should be even better than for a compiler, right? One of my pipe dreams is to answer all those "error message" complainers in the surveys with: we solved that (not down-stream by the various editor add-ons but) at its core with SCI.

I don't actually think that the errors in bb or SCI are better due to the interpreter but maybe we could talk about an example of how it's better in SCI vs JVM Clojure and see why, in another thread?

I write an example

(made the thread in public channel, let's continue there)

• I like the Babashka error messages better than the JVM-Clojure ones, so I use it whenever possible • Scittle has JS-interop and NRepl, so it is great for mutating objects of JS-libraries, e.g. I scale and move SVG graphics on the canvas of JSXGraph with immediate effect.