Just wanted to float an idea for you folks and gauge some opinions. I am not working on this that I am going to talk about, this is just an idea that has been floating in my mind for a while and if I don't talk about it I will end up forgetting it and never getting any feedback.
What about a playground for SSB?
As mentioned in other threads from @mix and @Matt McKegg, creating and experimenting with SSB is not as friction-free as we'd like it to be.
I think we'd benefit from a Playground for SSB software. I'd like to think of it as a little UI like a Lisp Listener, a REPL that would allow you to execute little scripts against the running sbot with a nice API.
This way, inventive users could just pick the app and toy with little scripts. The approach would be something similar processing in which not only you have a nice API but also some good visualization tools for the result of your toys. I don't mean this as in good enough for interactive graphical artists (which is hard to build) but at least something that goes beyond ASCII dumps.
I think that JS is the wrong language to build this as the facilities for executing scripts interactively are lacking. We can't trust
eval() not to mess the current environment and the language carries a ton of baggage these days in terms of associated tooling to benefit from the latest and greatest features. I've been thinking about using a different language to create these interactive environments, which would be possible once #sunrise-choir becomes more ready for experimentation.
All this talk is just context, I believe everyone would love to have such app. What I am trying to get specific feedback is on the two approaches forward outlined below.
The Lua approach
Lua is a fantastic tiny language. It is very speedy and easy to learn. It has been around for 25 years now and has carved some niches for itself. Some pros for this approach would be:
- Fantastic FFI interfaces (both in LuaJIT and PUC Lua) allowing us to interface well with #sunrise-choir or any other approach that is callable as a shared library with C conventions.
- Built for scriptability from the start. Lua has always been an engine that you're supposed to embed into a larger program to expose said program features to a scripts. It has a very good API for wrapping C stuff back and from Lua, which would allow us to create a really nice API.
- Lua is very good in executing Lua code with constraints. You, from inside a Lua program, can craft an little environment and choose what globals, what functions, what features, a runtime script can have access to, thus allowing you to execute code written at runtime without the danger of breaking the running environment. This is the main reason for me to use it over JS for this kind of app.
There is a software product called tarantool which is at the same time a non-relational database, an application server and a fast Lua engine. This app could be built on top of Tarantool with the feed going inside Tarantool database much like @Piet has been experimenting with SQLite but with the added benefit of having a full server and scripting engine in the same tool.
The final deliverable would be an engine. This engine has the SSB features and a running scripting environment offered as a REPL or something that works over Standard Input/Output thus also allowing to build little tools on top of it.
The Racket Approach
Racket is a language in the Lisp/Scheme family that is thought as a toolkit for building languages. I have used it in this talk about JS monoculture to build my own little programming language for crafting slideshows.
With Racket, we have the opportunity to build a little language that just suits SSB. Just like Perl knows all about handling text, we could just have a language that knows SSB. I don't mean a language in the Lisp family with an SSB API, I mean any language we want that has SSB as primitives in which it is built upon. The book Beautiful Racket is a very nice book on constructing small languages. Some more of the pros for Racket are:
- It has a good FFI as well, thus allowing us to leverage #sunrise-choir stuff just like the Lua approach above.
- Allows us to create a full language.
- Provides a rich environment with editors, graphics, interactivity out of the box for the language we create.
- Any language built with Racket can use the other languages built with it, this is very powerful as it allows us to craft a low level language (something like scuttlebutt system language) and then build a high-level language (like a buttscript) that uses the low-level language internally.
So, I have these two ideas in my mind. I have no idea if anyone finds them interesting. I am not working on them now, I am just collecting ideas for future projects. Personally, I think that the Racket approach might lead to a very good software in the end, something that is quite powerful. While the Lua one leads to faster stuff, both in terms of development time and also of execution time.
Anyone want to share some feedback?