This is a pretty awesome story about a bunch of attempts at a somewhat-visual, more accessible programming language: by @Katie Bell

Not sure why YouTube picked that Scratch slide as the most important slide (I guess it’s colourful?) but it’s not really about Scratch.

The talk is from, what, a year ago? I'm sure we'd love to see any new demos.

I also have this talk from September: which is further along and after I switched from JavaScript to Python as the base language.

Yes I already signed up on the mailing list. Happy to be a UX guinea pig.

Wow I never saw this before it's really good! I'll definitely give it a go

VERY impressive. I'm using Blockly for declarative logic programming, (speaking at the Blockly conference in 2 weeks) and I've been looking for a way to integrate this kind of text-completion method on top of the drag-and-drop interface. You've solved that problem completely. I only wish I knew how to duplicate the REPL experience in the language I'm using. Need to research that. Are languages and blocks modularized out in SplootCode, so I could theoretically create the blocks and code generation tools necessary to do logic programming (without the run/feedback features)? And just out of curiosity, have you considered the possibility of bi-directional translation, to ease people into being able to type the code themselves? TIA!

It's designed to have UI components that are reusable across different languages. So it can be adapted to another language, you need to implement a SplootNode subclass for each type of block (e.g. if, variable reference, operator) and implement a function or two that generate autocomplete suggestions for each node type. The nodetree then serialises to a nested Json object structure that you can use in your own compile/execution. So yeah, it is designed to be adapted to new languages but I've not put any effort into making this easy for people other than myself, and the APIs aren't stable. I can help answer questions if you're keen to give it a shot though! Because the underlying tree structure is basically the python AST it can in theory do bi-directional translation and I have code for that which I used in my tests. I've only got a subset of python supported though so importing from text code is not good enough to include in the UI yet. Also it would never be good at round-tripping because it'd lose all formatting and some syntax choices that generate the same AST. It's not a specific goal of the project to roundtrip with text.

I just got around to watching , and I'm particularly interested in your ability to record runtime inputs once and reuse them while iteratively modifying the program. How hard does it seem to extend this capability for the sorts of interesting programs you mentioned, Discord bots, 2D games and so on?

Currently it’s just capturing stdin only and re-running the entire app, but I have plans for more. In order to be able to replay a program deterministically you need to be able to capture all possible inputs. This includes little background things like random number generator seeds, the current time whenever it is read, etc. Currently it doesn’t do a good job of replaying if you use a random number or try to measure how long it takes for a user to provide input. For a Discord bot you need to capture request-response pairs (or a recording of whatever is streaming over a websocket) so it’s as easy as storing them and replaying them. If you decide to change the code to make a new request in a different order or with different parameters then well... it can’t replay that safely so it’d have to prompt the user to do another manual run. For a network heavy app like that most of the running time is waiting for the network so replays would be pretty fast. For a 2D game… that’s a lot harder to deterministically reproduce, especially at speed. You’d need to replay each mouse/keyboard event at the appropriate times in the main event loop, and you’d need to replay all the event/render loops with the same timestamp they originally occurred at - so if you take a 5min long capture of gameplay then well… replaying that could be pretty slow, even if you cut out all the sleeps, max out your CPU and skip the actual rendering. That is unless you can find a way to make it faster by snapshotting state and skipping steps. Inspiration for this (and considering that it might even be possible to deterministically record and replay programs) came from the RR project: https://rr-project.org/. They work at a very different level of abstraction though.

Yeah. I've been interested in this aspect for a long time. See this 2-minute video from last year, for example: https://archive.org/details/akkartik-mu-2021-05-31

I made a thing that captures Python execution then let's you replay it https://github.com/chrisknott/algojammer It saves a full dump of memory state every 200k interpreter steps, and between this it reruns the program in its own stripped down interpreter which is day. I pulled out the functionality into a library but I sort of gave up on it a while ago https://github.com/ChrisKnott/Execorder