Moving Scratch generation to Python on browser(kushaldas.in)
kushaldas.in
Moving Scratch generation to Python on browser
https://kushaldas.in/posts/introducing-ektupy.html
15 comments
Pygame would be the perfect use case for this. It also supports running in the browser via https://pypi.org/project/pygbag/
One possible consequence of generating Scratch by writing code is that you can ask an LLM to generate your Scratch. I worry that this could take away the fun of Scratch the same way I can no longer maintain any interest in going to Python night, because the computer can do it all.
See also!
Leopard[0] translates existing Scratch projects JavaScript with a a library for creating games with a really nice API for 'rendering sprites, collision detection, audio, and more'
and on the other side, goboscript[1] is a text based programming language that compiles to Scratch projects. It lets users write Scratch projects with text syntax that you can write in an IDE and version control etc.
maybe both of these could be interesting stepping stones? personally when I 'graduated' from Scratch as a kid I just dumped into writing HTML/CSS/JS websites, which is a very different environment entirely. It actually took a while before I realized where the overlap was with what I learned through Scratch.
[0] https://leopardjs.com/ https://github.com/leopard-js/leopard
[1] https://github.com/aspizu/goboscript
Leopard[0] translates existing Scratch projects JavaScript with a a library for creating games with a really nice API for 'rendering sprites, collision detection, audio, and more'
and on the other side, goboscript[1] is a text based programming language that compiles to Scratch projects. It lets users write Scratch projects with text syntax that you can write in an IDE and version control etc.
maybe both of these could be interesting stepping stones? personally when I 'graduated' from Scratch as a kid I just dumped into writing HTML/CSS/JS websites, which is a very different environment entirely. It actually took a while before I realized where the overlap was with what I learned through Scratch.
[0] https://leopardjs.com/ https://github.com/leopard-js/leopard
[1] https://github.com/aspizu/goboscript
Look really cool.
Only suggestion, if at all possible avoid special characters like @ and _ . In my experience, kids have a hard time to find them and it get even more complicated for non-english keyboard layouts.
Only suggestion, if at all possible avoid special characters like @ and _ . In my experience, kids have a hard time to find them and it get even more complicated for non-english keyboard layouts.
On the contrary, I would say, _ is relatively easy to type, and if they know how to type capital letters using Shift, they know to type underscores.
Nice idea! However I would like to smooth the transition by also having a Scratch layer with a "peek behind the curtains" button to see the equivalent python code
I like the direction youre moving. Would a drag and drop editor for Python syntax be useful for a project like this?
Having taught schoolkids both python and scratch, I feel that typing is better, but having the blocks visibly coloured as in scratch would be really useful
I have loved Scratch for many years. This looks cool! Thank you for sharing!
The music "boss_battle" rocks. Where does it come from?
Very helpful comments in much of the example code.
Looks fantastic.
Just curious, why not use Pygame?
Scratch abstracts away a ton of stuff to allow the student to focus on logical building blocks that mirror the mental model one might have when writing a real program. I'm wondering if keeping a lot of those abstractions when transitioning to text programming is educationally useful?
For example, it might not be clear that @on_forever is really just a loop, etc. One thing I've noticed when teaching beginners is that when you introduce a library/framework at the same time as a language, they start to form a model of the language that often wrongly includes parts of the library.
This is why I think Pygame is so useful for education, it sits at just the right level of abstraction for learning. In Pygame, your game loop is just a loop, handling input is just conditions in your loop, etc.
Regarding rewriting the AST to avoid async/await, do you have some experience or evidence to suggest that these should be abstracted out? I can see an argument for both sides, so just wondering how exactly you arrived at that decision.
Also, I tried a program with an infinite loop and the UI became unresponsive and I had to close the page. This indicates to me it's running on the main browser thread. Kids (and sometimes senior engineers) write infinite loops occasionally, so I highly recommend executing the user's code in a worker to prevent the harsh experience of losing your work suddenly.