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.