Show HN: Goboscript, text-based programming language, compiles to Scratch
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.
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.
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/
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.)
https://www.lazarus-ide.org/
https://news.ycombinator.com/item?id=43913414
https://hedy.org/
https://youtube.com/watch?v=ztdxlkmxpIQ
Getting fancy, that block could use a backend interpreter/compiler of choice, so the language could be Squeak, Python, C, an LLM generator, ...
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.
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.
Eventually, most things I built were nothing but code blocks.
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.
Maybe you could try something like that?
[0] https://developers.google.com/blockly/
[1] https://makecode.microbit.org/
https://www.blockscad3d.com/editor/
which uses it to wrap up (most of) OpenSCAD for interactive 3D modeling.
Check it out! https://leopardjs.com/
- 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
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.
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/
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
[1]: https://aspizu.github.io/goboscript/ [2]: https://aspizu.github.io/goboscript/install/#install-from-bi...
Thinking of it now, I wonder if the two approaches could be combined?
[1]: https://github.com/aspizu/sb2gs
These two are enough to build a programming language
[1]: https://github.com/scratchcpp/libscratchcpp
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...
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.
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.
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 probably wrong.
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.
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