I love teaching Scratch to kids. Some years ago, I used to do "CoderDojo", which is like a hobby club where kids can learn programming. Some kids go to soccer, others to art academy — and these kids learn programming. Super cool to teach.
However, most kids get stuck after they master Scratch. Especially kids around the age of 8–10. They learn Scratch. It's awesome. They make some advanced games and really get the hang of it.
Then they ask to do something more — some “real programming.” And that's where the hurdles start to pop up.
First problem: my kids don't speak English, so most documentation and tutorials are out of reach.
Second problem: suddenly they need to learn everything about computers — source files, graphics, networking... This is too big a hurdle for them to take.
Third problem: text-based programming. Most of them literally can't type on a keyboard properly. Text is also much less fun than visual programming.
What I've always wondered — and this project reminds me of it — is: can we make the transition smoother? Stay within the Scratch ecosystem, which they know, but start introducing extra concepts step by step, without the big jump.
GoboScript introduces "text-based programming" as a first step, while staying within the Scratch world. I would have liked it more if we could teach the kids a real-world programming language, like Python or JavaScript — because then they’re moving toward "real programming" step by step.
The next step would be: introduce other computer concepts like file systems or networking.
I would love to build this myself. Alas, no time. Maybe one day.
As a kid who didn't speak english I used the AutoIT language - not related to AutoHotKey
It's a got a fully localized offline documentation embedded in a plug-and-play IDE designed to always compile & run your code with a single F5 press, no configuration needed
The language itself is fully fledged but mostly revolves around things that kids already know.
The tutorial makes you leave the CLI stage by chapter 5, because when kids want to make software they want to make UIs, they've never used CLIs to do fun things before.
It's also centered around automating desktop tasks. Moving the mouse, typing keystrokes, downloading or opening web pages, parsing the source, identifying windows on screen, moving them around, reading pixels, playing sounds...
I loved AutoIT as a kid! And it was also fun playing around with stuff like https://www.perfectautomation.com/ (nice to see that it’s now freeware, and the newer replacement project is completely free / open source!).
But it was about the same time as I started digging around in Delphi 7, then discovered a RAD package pretty much exactly like Delphi, but with PHP instead (wild times), and as I was going down the webmaster route in parallel it was the thing I spent most of my days in. (That, and making bootleg Windows XP builds just for fun, of course.)
Lazarus is great and seems more stable than when I’ve last tried it. (~10 years ago, wow!) I don’t think I can come back to Pascal now, and I don’t really like this drag’n’drop GUI building method anymore, but it’s a great IDE otherwise!
I've done some research on this. I've asked classrooms of kids the words they would use to describe programming. When they are young in elementary school, the are taught Scratch, and describe programming as fun, exciting, challenging, favorite activity, something they look forward to.
Then I surveyed older kids, when they get to middle school and they transition immediately from scratch to Python and Java using VS Code. The words students use to describe programming take a dark turn: hard, frustrating, scary, not for me, are the top sentients. Programming starts up there next to recess in terms of K-6 approval rating, but plummets to to math class status in just a few years.
I attribute the change to language a tool design. This change in sentiment happens exactly when they are taken from tools designed for kids and forced to use tools designed for professional programmers. There's a chasm between Scratch and "real" programming languages. As lauded as Python is for being a good beginner or learning language, it does not fill that gap. In fact, it's part of the problem -- people believing it's a good enough first language prevents other perhaps better suited languages from being adopted. It may be a good language for dev-brained individuals, but for other people they can get discouraged very easily by it and the tooling ecosystem. I teach graduate students who find it perplexing, so middle school students don't stand a chance.
I wish I could upvote this twice, and I will go further.
Computing as a whole has a human factors problem. The people most able to fix this problem - programmers - are also the people who least recognize that there is a problem to fix. Indeed programmers are invested, both literally and subconsciously, in the current order. Programmers implicitly place themselves at the top of a computing class hierarchy that strictly categorizes "developers" and "users" by whether they pay or are paid, and developments that facilitate "normies" programming to a useful level are staunchly opposed. The current front line of this debate is LLM programming, which is a goddamned revolution as far as non-programmers are concerned, and programmers hate that non-programmers might be able to write programs, and tell scary stories about security vulnerabilities. But it's not new - before they were sneering at LLMs, they were sneering at LabVIEW, and telling scary stories about maintainability. Or Excel.
The smartphone revolution was really a user interface revolution, but in making computers accessible it also infantilized the users. This philosophy is now baked in to such an extent that not only are you not allowed root on most computers, but writing an "app" has an exponentially higher barrier to entry than writing a shell script, or even a basic Hello World in C. Programming is becoming harder, not easier. Compare to the 80s, when a child or teen's "game console" might have been a ZX Spectrum or Commodore 64, which would boot right to BASIC - a language which, incidentally, remains a much better introduction to programming than Python.
My thesis: The theory and practice of programming is permeated with the sensibilities of high-functioning autistics like myself. De-nerding programming will unlock great benefits for all of humanity. We too will benefit, for despite our hubris we are also way over our heads.
There's a great deal of truth to that. Programming languages are made by nerds, for nerds, and that's a problem in a world that is becoming more automated every day.
> Compare to the 80s, when a child or teen's "game console" might have been a ZX Spectrum or Commodore 64, which would boot right to BASIC
Fully agreed here! I had a very unsettling conversation with a student interested in making video games. He was 18, and in a CS degree program, and he has told me he had been into video games his whole life, but he never knew you could use the computer he had at home growing up to make them.
This floored me because like you, I had experience booting up an old PC and having access to a programming language right there. Mine was QBasic on DOS, and I used it to make a rudimentary Zork type text adventure game. I was 6 or 7, and tons of people my age had that same experience getting into programming.
I would have thought in the 30 years since that time, with the proliferation of computing devices and especially game creation software, that it would be more accessible today to get into gaming. And in some ways it is, but in many ways it's also been heavily monetized and walled off, to the point that every day people are discouraged from creating their own games. It's really quite sad, because we've actually learned a lot over the years about how to make computing more accessible to people, but we haven't invested enough in putting that knowledge into real products that people use.
Yeah, I first thought of Hedy too. It doesn't keep them within the ecosystem but it does address the gradual intro problem and the localization problem.
I had pretty much the exact same experience with Game Maker too. In retrospect, feels like a very powerful pedagogical tool. Even when I wasn't really trying to "learn coding" but rather I just wanted to make some games, I ended up learning to code
The fact that _most_ things could be done with drag-and-drop, but for some features you had to drop down to scripting, served as a really nice and gentle stepping stone to writing code.
I did the same gradual move, and I can remember being excited to get home from school because I might have solved some problem by letting it tick over in my head.
But I do remember thinking GML was amazing (it was fugly, kid), and struggling with C, because the language was so different. (These days, leap to love2D and Lua instead).
Just the idea of multiple languages was so foreign and impossible to me. Writing a raycaster in GML was possible, writing an event loop in C was insane... And these days picking up a language tutorial for something new is a hobby.
It sounds like you want the ability to instantiate a scratch block that contains a text box, which in turn contains the function body for the block? It would then be possible to incrementally write as little or as much as desired in text.
Getting fancy, that block could use a backend interpreter/compiler of choice, so the language could be Squeak, Python, C, an LLM generator, ...
I know this is probably a bit more advanced, but this suggestion reminds me of Blueprints w/ magic nodes in Unreal Engine. There is a plugin for Magic Nodes (https://forums.unrealengine.com/t/magic-nodes/121220) where you can enter C++ into a blueprint node that integrates into the blueprint system. Similar kind of UI could work well
> It sounds like you want the ability to instantiate a scratch block that contains a text box, which in turn contains the function body for the block ?
That is the escape hatch from all visual development environments. Having seen Talend and W4 in action, I know the end state of the process: a single block with everything in it - I'm barely caricaturing here.
Maybe the specific needs of early learners will keep the system from degenerating too fast but, the moment code goes in that is not visually represented in the environment's visual paradigm, coherence goes downhill fast and one starts longing for properly managed scripts.
As I see it, that the whole point in this case. Alexander wants to teach children how to program in text mode, but can't see the bridge from Scratch to text mode. With textboxes, the child can write small functions to start with. As they learn, they may well start making the blocks of code more complex. Eventually they might end up with a single block with everything in it, as you describe. At that point they ditch the Scratch "wrapper" and start using a typical text mode tool chain. Mission accomplished.
One of my children did something like this. In the days when Scratch was written in Squeak, he discovered that shift-clicking the 'r' in the Scratch logo dropped him into the underlying Squeak environment. He then started modifying and writing Scratch blocks and was eventually comfortable with text mode programming.
I’m familiar with the Grasshopper visual scripting environment for the Rhino CAD system, and what you’re describing happens there as well…but I don’t really perceive it as a negative. Users who aren’t comfortable with text programming continue to use the visual method, and users who are tend to migrate their more complicated functions to single blocks. There’s a limit of complexity beyond which the visual programming becomes an impediment to understanding. It’s OK if moving things to a text-based block will make the internal logic of that block inaccessible to some number of users, given that those users would struggle to understand the visual version of the function as well.
I still think Scratch has some brilliant ideas that aren't quite captured into traditional text-based programming languages. The fact that the types are rigid out to the editor (i.e. the editor will let you have a partially-formed program but not an invalid program because it does static type checking per-edit and rejects edits that don't pass) is quite a powerful feature tucked into a toy / educational language.
The solution I built for this is Leopard. It is a Scratch → JavaScript converter. You can take an existing Scratch project and convert it to JavaScript code and then keep working, or use the Leopard library to create a new project from (ahem) scratch, following all the same conventions as a Scratch project.
Flash circa 4-7 era had a really nice scripting environment for ActionScript where you could select instructions via a drop-down and edit fields for each instruction (with the fields being of dynamic input types). I've never seen something like these days, but for a 12 year old me it was really fun and simple to use. It also came with an integrated offline manual.
I loved learning and then mentoring at CoderDojos. Incredible meetups where they really let kids learn in their own way with guidance of more experienced coders. Very fun and I never had a bad experience. The ones I went to were at University of Minnesota.
I teach programming to designers and architects at the local university. We're using Processing quite successfully, because it skips a lot of steps. My daughters are too young and are still doing Scratch (with the great micro:bit). But I think next would be Processing, or Arduino with Micropython. But yes, typing is a problem. My older daughter inputs almost all her text via voice input. At work we're doing a lot of low code for new architectures. I think agentic low code tools for kids would be nice.
My initial take was to share this with my son who used to built all kinds of things in Scratch, but I know that the lack of simple install instructions will be a deal-breaker for him.
Given that (part of) your audience will be persons like my son graduating out of graphical programming in Scratch, it might be worth spending a little time on non-dev install instructions. Even more so as you can leverage the rust toolchain and just suggest something along `cargo install --git ...` [0], without even publishing as a crate.
Apologies if this comes across as entitled: I just want to communicate that a single README-sentence on top of the work you already put into this would make it significantly more accessible.
There are handful methods of installation documented in the documentation [1]. The easiest one being installing from git and cargo. For people who do not have the rust toolchain installed, the easiest method is to install pre-built binaries released on GitHub [2].
I got into coding through Scratch, and I've been involved with Scratch for over a decade now (I'm 18). I think an often overlooked aspect of Scratch is that it's more than just a drag and drop coding editor; there's an entire community site to share projects on too. And the site is super 'hackable', the APIs are fairly open and all of the client side code is open source too. There's a whole ecosystem of other kids building stuff for/around Scratch (like the Scratch Addons browser extension [0]), as well as projects like this.
To be honest, I learnt more from hacking Scratch than using it as intended. I thought this was just a 'me thing', but last summer I was an intern on the Scratch Foundation's engineering team, and my mentor explained that they're totally aware of this effect, and that they take it into account when designing the platform. I like Scratch.
This is great! I'd also like to mention pytch.org which takes a slightly different approach to the same problem, essentially recreating most of Scratch within python, and teaching learners how they'd go about writing code to do the same sort of stuff they would have done with Scratch, and then to extend it with python stuff that isn't possible in Scratch.
Thinking of it now, I wonder if the two approaches could be combined?
You can kinda do this using sb2gs [1], which is a decompiler for goboscript. It turns Scratch projects into text-based goboscript projects automatically, for people who wish to work on their Scratch projects in goboscript without having to manually port their entire project to goboscript. Though, sb2gs isn't the best at decompiling everything properly, so a few manual edits are required.
This is cool. Also check out Pico-8. I just learned about it and started showing it to my kids, ages 8 - 13. They all liked it and engaged with it to varying degrees.
It has a code editor with 8 tabs for organization and uses Lua with some extra functions for the game loop and sprites.
It has a built in sprite and map editor, plus sfx and music editor.
It reminds me of the integration and experimentation I had with TI Logo and Amiga Basic.
There is a free education edition available online.
Text is great for Git-based collaborative workflows. There's a reason why text-based programming languages are the standard today, and walled gardens like Smalltalk "images" and the old LISP machine environments have fallen out of use. Scratch is yet another walled garden.
Smalltalk has archived code in text files for like 40 years.
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
goboscript allows you to create advanced Scratch projects with ease, you can use any text editor, use a version control system such as git. You can refactor your code using search and replace. Text code can be copy pasted, which allows you to easily reuse code or share it with others. goboscript syntax is concise and easy to read.
goboscript allows you to integrate external tooling and workflows, such as using a script to generate costumes for a text rendering engine. Or loading in images into lists.
goboscript has a powerful macro system - similar to Rust's macro system. This allows you to write macros to generate code.
goboscript is more than just an 1:1 mapping of Scratch blocks to text, it also has additional features like local variables for procedures (custom blocks).
goboscript also performs optimizations, detects problems and unused code.
All of these new features are impossible in the visual programming paradigm.
> All of these new features are impossible in the visual programming paradigm.
I believe that to be not true. Visual paradigm allows for some interesting behaviours.
1. Integrate external tooling and workflows
This is just the result of the Scratch runtime being in the browser.
2. Macros
Okay, macros might seem very difficult in a visual paradigm, but its possible. And, in a visual paradigm, it would be very easy to visualize how macros transform the code. (You could have a pop-up that shows the expanded form of the macro)
3. Optimizations: Turbowarp is a Scratch mod that does JIT compilation with optimizations.
> All of these new features are impossible in the visual programming paradigm.
This is false. The logic is simple to see why. Text is limited to alpha numeric characters restricted in a format that’s from left to right lines. It’s a very arbitrarily specific way to represent a “program”
In fact text is in itself a visual program. It’s one set of arbitrary rules as outlined above on how to represent a concept visually.
Thus there are definitely ways to represent a program with different rules with more dimensions and much less restrictions.
I don’t know how people get in there heads that in visual programming things are “impossible.” Like it’s not even a subjective thing, it’s definitively wrong.
(Not OP) Scratch is great. Its an excellent first step. But you hit the limits fairly quickly for what is easy to do "reasonably". So you stay within the limits of what it does well and that limits the kinds of things you can do. And then you risk losing the kids interest to keep at it, if they become bored with the medium.
I think Roblox is not a bad next step (tons of out of the box marketplace options), or Ive also been doing a bit of Godot with my kids but with me driving a lot of it while we explore it together.
Making non-trivial things work in Scratch can be fun for similar reasons that it's fun to develop games for the NES in 2025, using modern tooling [0].
NES development would be easier if you upgraded the hardware to be more capable, but that would defeat the purpose. It could still be an interesting project in its own right, but it's not "solving" the same problem.
With Scratch, there are also fundamental practical limitations. Dragging stuff around with a mouse becomes a chore, once your code passes a modest size. Maybe you could invent a system of keyboard shortcuts, but that sounds even harder to use.
We already have mountains of excellent tools for working with text, from IDEs to git forges. It'd be really hard to build something competitive, for scratch blocks, from scratch.
Its just inherent to the environment and use case I think. They are very focused on their mission of being a very quick to start platform for children learning to program in a visual language. They do a good job. There isnt a great solution for "whats next", and this (goboscript) could be that.
where was this when i was making scratch games in elementary school?? would've been exponentially more efficient to write text instead of dragging blocks around.
Looks fantastic! Now it simply needs a non-Scratch runtime and a Scratch-like frontend, and we'll finally be able to teach bootstrapping to the 5-10 year old demographic.
adazem009 has been developing an alternative runtime for Scratch written in C++ [1]. It even uses compilation to speed-up the performance of Scratch projects, perfect runtime for goboscript projects.
On the contrary. I think it is an excellent bridge between visual and text-oriented programming. It also introduces concepts we take for granted elsewhere: return values from functions, text-based macro substitution, local variables, structs and enums.
Tell me more about scratch's purpose, please. I believe it's to teach programming. GoboScript seems a natural extension of already conventional environment to more "real" textual programming tasks.
I love teaching Scratch to kids. Some years ago, I used to do "CoderDojo", which is like a hobby club where kids can learn programming. Some kids go to soccer, others to art academy — and these kids learn programming. Super cool to teach.
However, most kids get stuck after they master Scratch. Especially kids around the age of 8–10. They learn Scratch. It's awesome. They make some advanced games and really get the hang of it.
Then they ask to do something more — some “real programming.” And that's where the hurdles start to pop up. First problem: my kids don't speak English, so most documentation and tutorials are out of reach. Second problem: suddenly they need to learn everything about computers — source files, graphics, networking... This is too big a hurdle for them to take. Third problem: text-based programming. Most of them literally can't type on a keyboard properly. Text is also much less fun than visual programming.
What I've always wondered — and this project reminds me of it — is: can we make the transition smoother? Stay within the Scratch ecosystem, which they know, but start introducing extra concepts step by step, without the big jump.
GoboScript introduces "text-based programming" as a first step, while staying within the Scratch world. I would have liked it more if we could teach the kids a real-world programming language, like Python or JavaScript — because then they’re moving toward "real programming" step by step.
The next step would be: introduce other computer concepts like file systems or networking.
I would love to build this myself. Alas, no time. Maybe one day.
As a kid who didn't speak english I used the AutoIT language - not related to AutoHotKey
It's a got a fully localized offline documentation embedded in a plug-and-play IDE designed to always compile & run your code with a single F5 press, no configuration needed
The language itself is fully fledged but mostly revolves around things that kids already know.
The tutorial makes you leave the CLI stage by chapter 5, because when kids want to make software they want to make UIs, they've never used CLIs to do fun things before.
It's also centered around automating desktop tasks. Moving the mouse, typing keystrokes, downloading or opening web pages, parsing the source, identifying windows on screen, moving them around, reading pixels, playing sounds...
https://www.autoitscript.com/site/autoit/
I loved AutoIT as a kid! And it was also fun playing around with stuff like https://www.perfectautomation.com/ (nice to see that it’s now freeware, and the newer replacement project is completely free / open source!).
But it was about the same time as I started digging around in Delphi 7, then discovered a RAD package pretty much exactly like Delphi, but with PHP instead (wild times), and as I was going down the webmaster route in parallel it was the thing I spent most of my days in. (That, and making bootleg Windows XP builds just for fun, of course.)
Fortunately, for Delphi we have an opensource successor:
https://www.lazarus-ide.org/
https://news.ycombinator.com/item?id=43913414
Lazarus is great and seems more stable than when I’ve last tried it. (~10 years ago, wow!) I don’t think I can come back to Pascal now, and I don’t really like this drag’n’drop GUI building method anymore, but it’s a great IDE otherwise!
I've done some research on this. I've asked classrooms of kids the words they would use to describe programming. When they are young in elementary school, the are taught Scratch, and describe programming as fun, exciting, challenging, favorite activity, something they look forward to.
Then I surveyed older kids, when they get to middle school and they transition immediately from scratch to Python and Java using VS Code. The words students use to describe programming take a dark turn: hard, frustrating, scary, not for me, are the top sentients. Programming starts up there next to recess in terms of K-6 approval rating, but plummets to to math class status in just a few years.
I attribute the change to language a tool design. This change in sentiment happens exactly when they are taken from tools designed for kids and forced to use tools designed for professional programmers. There's a chasm between Scratch and "real" programming languages. As lauded as Python is for being a good beginner or learning language, it does not fill that gap. In fact, it's part of the problem -- people believing it's a good enough first language prevents other perhaps better suited languages from being adopted. It may be a good language for dev-brained individuals, but for other people they can get discouraged very easily by it and the tooling ecosystem. I teach graduate students who find it perplexing, so middle school students don't stand a chance.
I wish I could upvote this twice, and I will go further.
Computing as a whole has a human factors problem. The people most able to fix this problem - programmers - are also the people who least recognize that there is a problem to fix. Indeed programmers are invested, both literally and subconsciously, in the current order. Programmers implicitly place themselves at the top of a computing class hierarchy that strictly categorizes "developers" and "users" by whether they pay or are paid, and developments that facilitate "normies" programming to a useful level are staunchly opposed. The current front line of this debate is LLM programming, which is a goddamned revolution as far as non-programmers are concerned, and programmers hate that non-programmers might be able to write programs, and tell scary stories about security vulnerabilities. But it's not new - before they were sneering at LLMs, they were sneering at LabVIEW, and telling scary stories about maintainability. Or Excel.
The smartphone revolution was really a user interface revolution, but in making computers accessible it also infantilized the users. This philosophy is now baked in to such an extent that not only are you not allowed root on most computers, but writing an "app" has an exponentially higher barrier to entry than writing a shell script, or even a basic Hello World in C. Programming is becoming harder, not easier. Compare to the 80s, when a child or teen's "game console" might have been a ZX Spectrum or Commodore 64, which would boot right to BASIC - a language which, incidentally, remains a much better introduction to programming than Python.
This reminds me of a tweet from a while back: https://x.com/jonathoda/status/960952613507231744
There's a great deal of truth to that. Programming languages are made by nerds, for nerds, and that's a problem in a world that is becoming more automated every day.> Compare to the 80s, when a child or teen's "game console" might have been a ZX Spectrum or Commodore 64, which would boot right to BASIC
Fully agreed here! I had a very unsettling conversation with a student interested in making video games. He was 18, and in a CS degree program, and he has told me he had been into video games his whole life, but he never knew you could use the computer he had at home growing up to make them.
This floored me because like you, I had experience booting up an old PC and having access to a programming language right there. Mine was QBasic on DOS, and I used it to make a rudimentary Zork type text adventure game. I was 6 or 7, and tons of people my age had that same experience getting into programming.
I would have thought in the 30 years since that time, with the proliferation of computing devices and especially game creation software, that it would be more accessible today to get into gaming. And in some ways it is, but in many ways it's also been heavily monetized and walled off, to the point that every day people are discouraged from creating their own games. It's really quite sad, because we've actually learned a lot over the years about how to make computing more accessible to people, but we haven't invested enough in putting that knowledge into real products that people use.
Maybe something like Hedy will work better for you, instead of Scratch.
https://hedy.org/
https://youtube.com/watch?v=ztdxlkmxpIQ
Yeah, I first thought of Hedy too. It doesn't keep them within the ecosystem but it does address the gradual intro problem and the localization problem.
This is how I learned a long time ago with Game Maker. Everything was Gui based, but you could also add code blocks to do more powerful things.
Eventually, most things I built were nothing but code blocks.
I had pretty much the exact same experience with Game Maker too. In retrospect, feels like a very powerful pedagogical tool. Even when I wasn't really trying to "learn coding" but rather I just wanted to make some games, I ended up learning to code
The fact that _most_ things could be done with drag-and-drop, but for some features you had to drop down to scripting, served as a really nice and gentle stepping stone to writing code.
Anecdote follows. The below matters little.
I did the same gradual move, and I can remember being excited to get home from school because I might have solved some problem by letting it tick over in my head.
But I do remember thinking GML was amazing (it was fugly, kid), and struggling with C, because the language was so different. (These days, leap to love2D and Lua instead).
Just the idea of multiple languages was so foreign and impossible to me. Writing a raycaster in GML was possible, writing an event loop in C was insane... And these days picking up a language tutorial for something new is a hobby.
Same, except for me it was Corel Click & Create.
It sounds like you want the ability to instantiate a scratch block that contains a text box, which in turn contains the function body for the block? It would then be possible to incrementally write as little or as much as desired in text.
Getting fancy, that block could use a backend interpreter/compiler of choice, so the language could be Squeak, Python, C, an LLM generator, ...
I know this is probably a bit more advanced, but this suggestion reminds me of Blueprints w/ magic nodes in Unreal Engine. There is a plugin for Magic Nodes (https://forums.unrealengine.com/t/magic-nodes/121220) where you can enter C++ into a blueprint node that integrates into the blueprint system. Similar kind of UI could work well
> It sounds like you want the ability to instantiate a scratch block that contains a text box, which in turn contains the function body for the block ?
That is the escape hatch from all visual development environments. Having seen Talend and W4 in action, I know the end state of the process: a single block with everything in it - I'm barely caricaturing here.
Maybe the specific needs of early learners will keep the system from degenerating too fast but, the moment code goes in that is not visually represented in the environment's visual paradigm, coherence goes downhill fast and one starts longing for properly managed scripts.
As I see it, that the whole point in this case. Alexander wants to teach children how to program in text mode, but can't see the bridge from Scratch to text mode. With textboxes, the child can write small functions to start with. As they learn, they may well start making the blocks of code more complex. Eventually they might end up with a single block with everything in it, as you describe. At that point they ditch the Scratch "wrapper" and start using a typical text mode tool chain. Mission accomplished.
One of my children did something like this. In the days when Scratch was written in Squeak, he discovered that shift-clicking the 'r' in the Scratch logo dropped him into the underlying Squeak environment. He then started modifying and writing Scratch blocks and was eventually comfortable with text mode programming.
I’m familiar with the Grasshopper visual scripting environment for the Rhino CAD system, and what you’re describing happens there as well…but I don’t really perceive it as a negative. Users who aren’t comfortable with text programming continue to use the visual method, and users who are tend to migrate their more complicated functions to single blocks. There’s a limit of complexity beyond which the visual programming becomes an impediment to understanding. It’s OK if moving things to a text-based block will make the internal logic of that block inaccessible to some number of users, given that those users would struggle to understand the visual version of the function as well.
This is done rather well in TouchDesigner
I still think Scratch has some brilliant ideas that aren't quite captured into traditional text-based programming languages. The fact that the types are rigid out to the editor (i.e. the editor will let you have a partially-formed program but not an invalid program because it does static type checking per-edit and rejects edits that don't pass) is quite a powerful feature tucked into a toy / educational language.
Would something like Blockly [0] or MakeCode [1] fill that gap?
[0] https://developers.google.com/blockly/
[1] https://makecode.microbit.org/
An interesting usage of Blockly is BlockSCAD:
https://www.blockscad3d.com/editor/
which uses it to wrap up (most of) OpenSCAD for interactive 3D modeling.
For a textual teaching language check out https://hedy.org It is multilingual (not just English) and introduces syntax gradually
The solution I built for this is Leopard. It is a Scratch → JavaScript converter. You can take an existing Scratch project and convert it to JavaScript code and then keep working, or use the Leopard library to create a new project from (ahem) scratch, following all the same conventions as a Scratch project.
Check it out! https://leopardjs.com/
Flash circa 4-7 era had a really nice scripting environment for ActionScript where you could select instructions via a drop-down and edit fields for each instruction (with the fields being of dynamic input types). I've never seen something like these days, but for a 12 year old me it was really fun and simple to use. It also came with an integrated offline manual.
Maybe you could try something like that?
I loved learning and then mentoring at CoderDojos. Incredible meetups where they really let kids learn in their own way with guidance of more experienced coders. Very fun and I never had a bad experience. The ones I went to were at University of Minnesota.
I teach programming to designers and architects at the local university. We're using Processing quite successfully, because it skips a lot of steps. My daughters are too young and are still doing Scratch (with the great micro:bit). But I think next would be Processing, or Arduino with Micropython. But yes, typing is a problem. My older daughter inputs almost all her text via voice input. At work we're doing a lot of low code for new architectures. I think agentic low code tools for kids would be nice.
You use case is exactly what hedy tackles, your experience is really similar to what the author of Hedy tells in conference and interviews.
https://easylang.online/ide/
have you tried showing them LabVIEW? it ticks tons of boxes:
- graphical
- more advanced (inherently parallel, more useful async data structures like events and queues)
- interfaces with tons of cool hardware
- built in network programming
- pretty powerful debugging
- free with community edition
Once they have the basics down, you could transition them out to a text based language slowly, even using the c/Matlab based text nodes to start
Thank you for making this!
My initial take was to share this with my son who used to built all kinds of things in Scratch, but I know that the lack of simple install instructions will be a deal-breaker for him.
Given that (part of) your audience will be persons like my son graduating out of graphical programming in Scratch, it might be worth spending a little time on non-dev install instructions. Even more so as you can leverage the rust toolchain and just suggest something along `cargo install --git ...` [0], without even publishing as a crate.
Apologies if this comes across as entitled: I just want to communicate that a single README-sentence on top of the work you already put into this would make it significantly more accessible.
[0]: https://doc.rust-lang.org/cargo/commands/cargo-install.html
There are handful methods of installation documented in the documentation [1]. The easiest one being installing from git and cargo. For people who do not have the rust toolchain installed, the easiest method is to install pre-built binaries released on GitHub [2].
[1]: https://aspizu.github.io/goboscript/ [2]: https://aspizu.github.io/goboscript/install/#install-from-bi...
I got into coding through Scratch, and I've been involved with Scratch for over a decade now (I'm 18). I think an often overlooked aspect of Scratch is that it's more than just a drag and drop coding editor; there's an entire community site to share projects on too. And the site is super 'hackable', the APIs are fairly open and all of the client side code is open source too. There's a whole ecosystem of other kids building stuff for/around Scratch (like the Scratch Addons browser extension [0]), as well as projects like this.
To be honest, I learnt more from hacking Scratch than using it as intended. I thought this was just a 'me thing', but last summer I was an intern on the Scratch Foundation's engineering team, and my mentor explained that they're totally aware of this effect, and that they take it into account when designing the platform. I like Scratch.
[0] https://scratchaddons.com/
This is great! I'd also like to mention pytch.org which takes a slightly different approach to the same problem, essentially recreating most of Scratch within python, and teaching learners how they'd go about writing code to do the same sort of stuff they would have done with Scratch, and then to extend it with python stuff that isn't possible in Scratch.
Thinking of it now, I wonder if the two approaches could be combined?
Next step: create a visual programming language that compiles to goboscript.
You can kinda do this using sb2gs [1], which is a decompiler for goboscript. It turns Scratch projects into text-based goboscript projects automatically, for people who wish to work on their Scratch projects in goboscript without having to manually port their entire project to goboscript. Though, sb2gs isn't the best at decompiling everything properly, so a few manual edits are required.
[1]: https://github.com/aspizu/sb2gs
This is cool. Also check out Pico-8. I just learned about it and started showing it to my kids, ages 8 - 13. They all liked it and engaged with it to varying degrees.
It has a code editor with 8 tabs for organization and uses Lua with some extra functions for the game loop and sprites.
It has a built in sprite and map editor, plus sfx and music editor.
It reminds me of the integration and experimentation I had with TI Logo and Amiga Basic.
There is a free education edition available online.
Why is text preferable to scratch? What is fundamentally wrong with scratch to make this transition desirable?
Text is great for Git-based collaborative workflows. There's a reason why text-based programming languages are the standard today, and walled gardens like Smalltalk "images" and the old LISP machine environments have fallen out of use. Scratch is yet another walled garden.
> There's a reason why…
Incumbency advantage.
Free as-in beer versus commercial proprietary.
etc.
> walled gardens like Smalltalk "images"
Smalltalk has archived code in text files for like 40 years.
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Smalltalk can be written with MS Notepad, imported and incrementally compiled with fileIn, and run.Using a designed for Smalltalk IDE will likely be more productive.
goboscript allows you to create advanced Scratch projects with ease, you can use any text editor, use a version control system such as git. You can refactor your code using search and replace. Text code can be copy pasted, which allows you to easily reuse code or share it with others. goboscript syntax is concise and easy to read.
goboscript allows you to integrate external tooling and workflows, such as using a script to generate costumes for a text rendering engine. Or loading in images into lists.
goboscript has a powerful macro system - similar to Rust's macro system. This allows you to write macros to generate code.
goboscript is more than just an 1:1 mapping of Scratch blocks to text, it also has additional features like local variables for procedures (custom blocks).
goboscript also performs optimizations, detects problems and unused code.
All of these new features are impossible in the visual programming paradigm.
> All of these new features are impossible in the visual programming paradigm.
I believe that to be not true. Visual paradigm allows for some interesting behaviours.
1. Integrate external tooling and workflows
This is just the result of the Scratch runtime being in the browser.
2. Macros
Okay, macros might seem very difficult in a visual paradigm, but its possible. And, in a visual paradigm, it would be very easy to visualize how macros transform the code. (You could have a pop-up that shows the expanded form of the macro)
3. Optimizations: Turbowarp is a Scratch mod that does JIT compilation with optimizations.
> All of these new features are impossible in the visual programming paradigm.
This is false. The logic is simple to see why. Text is limited to alpha numeric characters restricted in a format that’s from left to right lines. It’s a very arbitrarily specific way to represent a “program”
In fact text is in itself a visual program. It’s one set of arbitrary rules as outlined above on how to represent a concept visually.
Thus there are definitely ways to represent a program with different rules with more dimensions and much less restrictions.
I don’t know how people get in there heads that in visual programming things are “impossible.” Like it’s not even a subjective thing, it’s definitively wrong.
(Not OP) Scratch is great. Its an excellent first step. But you hit the limits fairly quickly for what is easy to do "reasonably". So you stay within the limits of what it does well and that limits the kinds of things you can do. And then you risk losing the kids interest to keep at it, if they become bored with the medium.
I think Roblox is not a bad next step (tons of out of the box marketplace options), or Ive also been doing a bit of Godot with my kids but with me driving a lot of it while we explore it together.
Why not extend the language itself to have the features we want? Why turn it into text?
Making non-trivial things work in Scratch can be fun for similar reasons that it's fun to develop games for the NES in 2025, using modern tooling [0].
NES development would be easier if you upgraded the hardware to be more capable, but that would defeat the purpose. It could still be an interesting project in its own right, but it's not "solving" the same problem.
With Scratch, there are also fundamental practical limitations. Dragging stuff around with a mouse becomes a chore, once your code passes a modest size. Maybe you could invent a system of keyboard shortcuts, but that sounds even harder to use.
We already have mountains of excellent tools for working with text, from IDEs to git forges. It'd be really hard to build something competitive, for scratch blocks, from scratch.
[0] https://github.com/llvm-mos/llvm-mos-sdk
Agreed.
Existing tooling is literally the only reason why.
But there is nothing inherently better about text.
Have you used Scratch before?
Its just inherent to the environment and use case I think. They are very focused on their mission of being a very quick to start platform for children learning to program in a visual language. They do a good job. There isnt a great solution for "whats next", and this (goboscript) could be that.
where was this when i was making scratch games in elementary school?? would've been exponentially more efficient to write text instead of dragging blocks around.
Looks fantastic! Now it simply needs a non-Scratch runtime and a Scratch-like frontend, and we'll finally be able to teach bootstrapping to the 5-10 year old demographic.
adazem009 has been developing an alternative runtime for Scratch written in C++ [1]. It even uses compilation to speed-up the performance of Scratch projects, perfect runtime for goboscript projects.
[1]: https://github.com/scratchcpp/libscratchcpp
This is hilarious yet awe inspiring at the same time. Great work
This is beautiful, and brings back so much nostalgia!
I love it! It has features that I'd have liked Scratch to have, like return values from functions, local vars, structs etc.
In Not in
These two are enough to build a programming language
This is hilarious because it defeats the purpose of scratch.
On the contrary. I think it is an excellent bridge between visual and text-oriented programming. It also introduces concepts we take for granted elsewhere: return values from functions, text-based macro substitution, local variables, structs and enums.
Tell me more about scratch's purpose, please. I believe it's to teach programming. GoboScript seems a natural extension of already conventional environment to more "real" textual programming tasks.