Make Scratch simpler to modify (formerly: implement Scratch in Smalltalk again)

o97doge

bump

o97doge

bump

EngineerRunner

support because smalltalk is sick and has a much lower barrier for entry compared for scratch 3 modding

o97doge

bump

rdococ

Scratch 3 modding has proved to be easier than I thought once you have the requisites set up properly (which requires a fair bit of know-how). However, I do think Scratch 4 should be implemented in something easier to get into than JS, React, NPM, node and all the other technologies used in Scratch 3. It could be implemented along with a version of Morphic in plain JS like Snap!.

Last edited by rdococ (Nov. 1, 2023 22:43:50)

o97doge

bump

o97doge

bump

gilbert_given_189

gilbert_given_189 wrote:
NanoRook wrote:
This is the big thing. I remember attempting to learn Squeak (struck me as the most popular Smalltalk implementation) and being baffled at how much community there wasn't. The wiki was barely maintained, the news section hadn't been updated since 2018, and most learning resources are ancient. Same with standard Smalltalk. I don't think it helps that the syntax feels deranged compared to modern programming syntax.
This.

I know Python does it a little with the indent-dedent system, but everything on Smalltalk feels unorthodox and esoteric. I'm fortunate enough to at least know little concepts of the syntax from venturing on the esolanging world (and the fact that most of Squeak self-documents itself), making the learning process a bit easy, but imagine if you're just starting out JavaScript, Lua, or God forbid Scratch. To them, Smalltalk feels back to front, with programming aspects they don't know why it works, but is necessary for reasons unknown to them.

You put your “actions” after the values, contrary to what you have learned on your usual programming class. You can't just define a variable on a line, you have to delimit some variables on vertical lines after the function name for some reason. What you may see as code blocks are actually functions, yet you don't know them because you're accustomed to how functions work on other C-style proglangs. It's a good way to introduce FP, yes, but for them all of these “bizarre” syntax quirks made the Smalltalk language virtually inaccessible to people that came from other, more popular proglangs. On this perspective, Smalltalk-based Scratch would be as hard, if not harder to mod than later version of Scratch, even though technically it's not.

Look, I know I've been talking smack with Smalltalk lately, but that doesn't mean I hate the language. I wouldn't say it's superior to others (in fact I feel it's lacking in nice points) but it's still a unique and interesting language. Now let's talk why this suggestion is… radically mediocre.

What does Smalltalk excel at while JavaScript (and some popular proglangs) doesn't? Both are object-oriented, self-modifying, integrates with the GUI, and has great documentation. The object browser of Smalltalk is nice, but there's nothing that your browser's debugger or an IDE can't provide. Besides, who wants to mod Scratch within itself anyway?

Also, can't we just talk about how unnecessarily bizarre the grammar is?
Here, how would you indent this code?

World allMorphsDo: [:morph | (morph externalName includesSubstring: 'h') ifTrue: [Transcript show: morph.].].

If you're used to handling any C-like languages, you might indent them like this:

World allMorphsDo: [:morph | 
    (morph externalName includesSubstring: 'h') ifTrue: [
        Transcript show: morph.
    ].
].

But nope! Smalltalk rejects that input. The correct way to indent it is like this:

World allMorphsDo: 
    [:morph | (morph externalName includesSubstring: 'h') ifTrue: [Transcript show: morph.].].

Oh by the way, don't confuse #includesSubstring with #includesSubString. Those are two different messages.

Why am I turning into the host of Proglang Critic?

I agree that developing Scratch 3 is not for the faint of heart. I personally tried to mod Scratch 3 myself, before giving up shortly after since the code is a literal lasagna code. But the way to fix this is not to switch to another language. No, what we would need is a better framework, made to be as extendible and hackable as possible.

Here, I have an idea. Take Scratch 1.4, and then port it word for word to JavaScript (not run the image using it). JavaScript already has the tools to substitute things like Objects, Morphs, etc., and we would most likely need a shim or two (especially for Morphs). In the end, we will get a version of Scratch that is almost as hackable as Scratch 1.4 if it were written on Smalltalk.

Update: Turns out morphic.js exists…

Last edited by gilbert_given_189 (Dec. 3, 2023 01:08:27)

gdfsgdfsgdfg

I mean there is such thing as the JS port of the language
smalltalk actually works on newer versions of operating systems
atleast on windows

Last edited by gdfsgdfsgdfg (Nov. 21, 2023 16:22:49)

o97doge

bump uwu

o97doge

bumpy wumpy (sorry if too early, nono word is broken right now)

retro_person

Support. As OP mentioned, this would be great for the extensibility of Scratch as a whole, but I also understand some of the counterarguments people have posed. All in all, though, I believe it would encourage people to get into Scratch modding and figure out how Scratch works internally.

o97doge

bump

rdococ

gilbert_given_189 wrote:
Here, I have an idea. Take Scratch 1.4, and then port it word for word to JavaScript (not run the image using it). JavaScript already has the tools to substitute things like Objects, Morphs, etc., and we would most likely need a shim or two (especially for Morphs). In the end, we will get a version of Scratch that is almost as hackable as Scratch 1.4 if it were written on Smalltalk.

Update: Turns out morphic.js exists…

Snap! is written using morphic.js in a similar object-oriented style to Scratch 1.x, and while it's not live, it is indeed much easier to mod than Scratch 3. I'm happy with Scratch 4 being written in a similar way.

Last edited by rdococ (Dec. 23, 2023 22:44:03)

ajskateboarder

Bump. I read some docs on various visions of object-oriented programming and message-passing and all that, and, despite some being antiquated, I feel enlightened, and want to suggest some features. Not sure if these suggestions are in scope of this topic, but I do know they would improve the modding experience. I'm not sure if I support using Smalltalk, but perhaps morphic.js or a similar library would work well. JavaScript seems to be a first programming language for most people nowadays

- Block extensions should be simpler to make and have a more central API. I'm not really a huge fan of having to create a giant object that describes the layout of the block.

- Executing instructions on the Scratch VM should be more predictable. It's scarcely documented and internalized for the most part, which sucks since that's basically the only way to modify a project's state.

- I dug into the code for about 20 minutes to learn that the VM either uses util.someFunction to receive values and runtime.emit(BlockCategory.BLOCK) to run actions. Maybe consolidate VM execution a bit more as well?

- Scripts should be assignable to various events in the GUI, such as when a project starts. These scripts could also be configured to run before or after the event

- All scripts and blocks should be accessible through an AST generator, or maybe a DOM structure if you don't want to analyze entire scripts, and should be iterable and modifiable as necessary. Not like the nonsense that is Blockly.js.

Here's a demonstration script with some of the above points in mind, which runs before the green flag is clicked. It simply takes every “move (x) (y)” block from a sprite and increments the x value by 100 during the program execution (the change would be temporary). I know it's a pretty silly script, but it's just to demonstrate the better modding capabilities

let scripts = editor.getSprite("flying-cat").getScripts()
class MyScriptVisitor extends ScriptVisitor {
  constructor() { this.moveNodes = [] }
  visitMoveXY(node) {
    this.moveNodes.push(node)
  }
}
let moveXYBlocks = new MyScriptVisitor().visit(scripts)

or

let moveXYBlocks = scripts.map(script => script.getBlocks("moveXY")).flatMap(e => e)

Yes, the above code intentionally bares a lot of similarities to document.querySelector because IMO, it's a good way to select elements

moveXYBlocks.forEach(block => {
  block.x += 100
})

I'm using JS here, but it could be a different language or framework. The one-liner code using maps is probably a bit cumbersome, so maybe there could be a better interface for selecting specific blocks and modifying them at runtime.

Thanks for coming to my Ted talk

Last edited by ajskateboarder (Jan. 5, 2024 00:58:08)

o97doge

Bump. (Also, live editing could be an alternative to this.)

Last edited by o97doge (Feb. 10, 2024 23:11:57)

o97doge

Bump.

o97doge

Bump.

BigNate469

What about mobile support? The whole reason 3.0 is written in JavaScript is because tablets don't run smalltalk or Flash. To keep that support, there would still have to be a JS version of it, and even if you port it, this could still create a lot of confusion and make things difficult for those modding Scratch, having to essentially mod two different things.

CST1229

In my opinion, most of the pain of modding Scratch 3.0 comes from the multiple git repos that have to be linked, and the overall spaghetti code structure; for example, to add a core block, you have to modify 3 separate repositories (scratch-blocks, vm and gui).
Maybe for a future rewrite, to make modding easier:

Use a monorepo structure, having all parts of Scratch in one repository. This means users would only have to fork and clone one GitHub repository to be able to modify all of Scratch's code, instead of having to do an awkward linking process.
Consolidate block making into one place (e.g turn the core categories into the extension format, which was actually planned during 3.0's development)
Might just be because I don't like React (i'm more of a Svelte guy), but maybe write the GUI in a framework that isn't React?
Make it easier or automatic to comply with Scratch's trademark policies, like a toggle that removes the Scratch logo and sprites. (The 1.x source code did this, with the “Based on Scratch from the MIT Media Lab” that comes by default)
Use up-to-date dependencies.

Discuss Scratch