hy VS sci

Not exactly the same (doesn't embed into the source like this did), but I believe Hylang[0] is the best Lisp package available for modern Python.

[0] https://github.com/hylang/hy

Isn't that a bit what hy (https://hylang.org/) tries to do ? AIUI it is a lisp interacting directly with the AST of Python, allowing seamless interop: Python modules can be used from hy and vice versa, everything is transparent.

I’ve been keeping loose tabs on this and Hy[1] for a while, but I’ve had some trouble figuring out the major differences between them and the use-cases for either. Would love to see an in-depth comparison in the form of a blog post sometime (though maybe the answer here is to do the research and write one up myself).

1: https://hylang.org

“Python is for scientists. Lisp is for engineers.”

Then what does that make Hy language?

https://hylang.org/

Re Languages with lots of example code and LLM’s

With translators or things like Hy lang, one could get the LLM’s to solve your problem in Python before converting it to another form. Then, you just need a translator. If lacking one, it’s easy to translate by hand.

The practicality of this concept will probably vary by use case. My experiments had GPT doing sketching, implementations, boilerplate, and even porting Python to Rust. A legally-clear LLM trained on multiple languages could probably be fine-tuned to do Python to LISP conversions. If not, Hy might be a stepping stone, too.

You could say so: I've been maintaining the compiler since 2016 ;). Infinitesimal Quest 2 + ε (SQ) exists more to advance Hy than for its own sake.

If you are using Python - you might find Hylang (https://hylang.org) interesting.

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.