yazz VS sci

Shameless plug. My own one of course :)

https://github.com/yazz/yazz

You can also try one I am building, a cross between Visual Basic and Microsoft Access here:

https://yazz.com/

i am working on such a thing myself at https://github.com/yazz/yazz. Also there are many other people trying to build something similar

I keep hacking away on Yazz for over 10 years now.... even if there is zero payoff I keep hacking... and that is what hackers do... we are not doing for the money... https://github.com/yazz/yazz

I really loved this talk and feel for Evan. As someone who was a VC/Angel investor in the space (I was the initial angel investor for something called LightTable/Eve) back in the day, worked for a couple of years at Red Hat, and am working on my own Open Source Language here: https://github.com/yazz/yazz (so yes, you could say I am a VC trying to build a low code product with my own hands), so I feel I have a valid opinions on this. I think that it is possible to make money in opensource as a little guy, but you need to have a combination of consulting, hosting, and support services. If your product is not able to encapsulate being sold and packaged as something that is possible to demo and sell to customers then you will most likely struggle to make a living from it

I am actually trying to make an open source successor, but using Javascript instead of Basic, at https://github.com/yazz/yazz and a demo at yazz.com

I'm still building a low code system with an easy to use component marketplace where you can edit components within the low code tool. Still a work in progress: https://github.com/yazz/yazz

Author of a framework that also stores it's code in IPFS for easy sharing (https://github.com/yazz/yazz). ScrapScript is a really nice concept with how it stores code. I originally got the idea for storing the code as a hash of the contents from Unison, and it looks like the idea is really starting to catch on with more and more languages now. Well done!

I’m working on a low core project that is already using content addressable source code that is stored in IPFS at https://github.com/yazz/yazz so it can be done

There are already some Dbos type systems out there. I built one which stores program state in SQLite databases and process state and programs are also stored in SQLite. In the oat I believe things like silver stream did the same too. The project I made is open source too: https://github.com/yazz/yazz

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.