joyride VS sci

I haven’t used VS Code so I don’t know, but I wonder if Joyride with Clojure gives you the functionality of evaluating code and change the environment interactively https://github.com/BetterThanTomorrow/joyride

This is a perfect example for when you want to use Joyride. You find examples and a presentation video where I demo some examples, here: https://github.com/BetterThanTomorrow/joyride/tree/master/examples Feel invited to start a discussion here https://github.com/BetterThanTomorrow/joyride/discussions and we will be happy to help you get this script created.

This is the kind of editor scripting that Emacs users take for granted. Now VS Code users can too. Check here for some pointers on how to leverage user space scripting of VS Code: https://github.com/BetterThanTomorrow/joyride

This is why we created Joyride, which lets you script VS Code in user space. Not only that, it gives you a REPL letting you control VS Code and modify your script as they are running. The main inspiration comes from Emacs, the definition of a hackable editor. https://github.com/BetterThanTomorrow/joyride

What if you could script and control VS Code with a REPL, like you can do with Emacs? What if it is a Clojure REPL? Leveraging SCI, this is what Joyride (https://github.com/BetterThanTomorrow/joyride) lets you do. We'll take a look at what possibilities this opens, what the limitations are, and what people have done with Joyride so far, four months since the first release.

Thanks! Please consider filing your suggestion here as an idea on the Joyride discussions section: https://github.com/BetterThanTomorrow/joyride/discussions

I've tried researching this myself and can't find too much. There's this project metaes which is an mci for JS, and there's the SCI module of the Clojure babashka project, but that's about it. I also saw Triska's video on mci but it was pretty theoretical.

https://github.com/babashka/SCI if it's a requirement for proper sandboxing

Since cherry is a compiler, the code generally runs faster than with SCI which is an interpreter. For many cases SCI is fast enough, but numerical computations in a hot loop isn't one of its strenghts:

Startup and sustained performance are absolutely implementation issues. For example, SBCL will take its sweet time to make machine code out of Common Lisp, but CLISP will interpret and generate bytecode. Both are useful, and both implement the same language. Clojure on the JVM takes also takes plenty of time to start up, so some use an interpreter instead. Furthermore neither of these languages has a cost model, so the cost of anything is an implementation issue.

So far we have relied on an increasing number of home-grown integration points to our platform, where relevant combined with the excellent SCI (so we can write some Clojure-code when adhoc data conversions / calculations / tweaking is required).

Also take a look at SCI, https://github.com/babashka/sci/blob/master/doc/libsci.md

You probably want to take a look at sci if you are creating a DSL or want to use Clojure itself as your DSL.

Built with the lovely SCI library (https://github.com/babashka/sci) + GraalVM, probably the most useful GraalVM project I've seen in the wild so far.

Also, Babashka will probably always support more features than ClojureRS could ever, particularly the interop with the various Java classes/functions, as that'd be very hard to achieve in ClojureRS.