4 ms·

I teach Scratch to children professionally. It is such a brilliant learning tool—except for one thing that annoys me so much! One of the first things we have k

I teach Scratch to children professionally. It is such a brilliant learning tool—except for one thing that annoys me so much! One of the first things we have kids try to create is a game called "Ghostbusters". The first step is "make your ghost hide and show every two seconds." Nearly every student codes something like this: forever hide show ⬏ The result is a ghost that does not do anything. Not the best introduction! I always tell the kids some variation of "the computer is going too fast", so they'll add a wait block. Their code need the wait block anyway, but it would be better if they could see what was happening and figure it out on their own. Also, my explanation is actually bullshit. Think about it—the ghost should be hidden as often as it's visible. Furthermore, if the kid does: forever show hide ⬏ ...their ghost will disappear and never reappear! Can you figure out what's happening yet? Well, consider this. If you do: move 10 steps move 10 steps move 10 steps ...your sprite will jump forwards 30 pixels all at once. But, if you do: repeat 3 times move 10 steps ⬏ ...then the sprite will animate forward, moving ten pixels per frame for three frames. Scratch only updates the screen at set "yield points", which are basically any instruction containing the word "wait" (reasonable enough) and after each iteration of a loop (very problematic). Loops should not have side effects! It's much more difficult to teach iteration when the unrolled version does something completely different! But the problem is deeper than that—it pops up everywhere with basically every student I work with, because it prevents kids from seeing the results of their code! Fundamentally, two blocks in the same script which request a screen update should not be able to run on the same frame. (Unless the user has enabled turbo mode, which is already an option for advanced users who need to push the limits of the language.) I know that all languages have quirks, but I just don't know what Scratch's developers were thinking here, or why I seem to be the only person who considers this a massive problem! I made a fork of Scratch which fixes this problem, but I'm not really sure what to do with it. Without a backend for saving projects to the cloud, I can't realistically use it in my classes. I've been trying to add a backend, but the code is undocumented and I have zero experience with backend development. https://github.com/LLK/scratch-vm/compare/develop...Wowfunhappy:scritch-vm:develop https://github.com/LLK/scratch-vm/compare/develop...Wowfunha...

jaltekruse 4y ago
Have you tried to open a PR on the main project? No idea how welcoming they are to outside contributors, but feedback from an instructor, complete with code to fix a pedigogical problem, I would be surprised if they didn't at least give it some consideration.
- Wowfunhappy 4y ago
  Unfortunately, Scratch's stated policy is that they don't accept accept PR's from outside contributors unless they address an issue marked "help wanted". This is also a breaking change, and it does make Scratch a lot less performant.
  - jaltekruse 4y ago
    Fair enough, I haven't looked at contributing myself so I was not aware of the policy. I do think it might still be worth trying to reach out to their team to see what their thoughts are about the issue you experienced. I'm sure it could be an uphill battle, but something like this might warrant a toggle-able "debug-friendly" mode that wouldn't be as concerned with performance. I could image possibly extending this principle to make repaints happen much more often, possibly even with a deliberate short pause after each repaint (which you might have already done) to avoid super fast jittering confusing a student's path to understanding loops or the speed of computations allowing them to hide bugs in a string of instructions that don't have one of these wait commands or "critical points" in execution to force a repaint to help them understand the current state.
  - netr0ute 4y ago
    Time to make a fork and use that for teaching instead
    - Wowfunhappy 4y ago
      I’d like to! Scratch’s backend is closed source. The open source version lets you save and load projects locally, but that’s a nonstarter for my classes, where most students work on different computers each day. I did have some success last weekend getting my fork to send a project’s data to a Cloudflare worker (where I can store it via Workers KV), but past that point I feel a bit stuck. None of this code is documented and I don’t have any backend experience. I think I need some sort of actual account and login system so that students can access all of their past projects. I'll probably keep poking at it, I'm just not sure I'll get anywhere. Other prominent forks such as Turbowarp don’t have cloud saving either, and now I think I understand why. It’s kind of frustrating tbqh. Scratch isn’t a good open source project if it’s centralized around a single host. I expect this of corporations who ultimately need to cultivate a customer base, but Scratch is an academic initiative from a prominent university. I understand why the backend is closed source, but I wish they provided clear documentation on how to hook it up to something else. (I also realize that like everyone in academia, they're probably understaffed and overworked, and I really do respect the tool they've built.)

jaltekruse 4y ago

Have you tried to open a PR on the main project? No idea how welcoming they are to outside contributors, but feedback from an instructor, complete with code to fix a pedigogical problem, I would be surprised if they didn't at least give it some consideration.

Wowfunhappy 4y ago
Unfortunately, Scratch's stated policy is that they don't accept accept PR's from outside contributors unless they address an issue marked "help wanted". This is also a breaking change, and it does make Scratch a lot less performant.
- jaltekruse 4y ago
  Fair enough, I haven't looked at contributing myself so I was not aware of the policy. I do think it might still be worth trying to reach out to their team to see what their thoughts are about the issue you experienced. I'm sure it could be an uphill battle, but something like this might warrant a toggle-able "debug-friendly" mode that wouldn't be as concerned with performance. I could image possibly extending this principle to make repaints happen much more often, possibly even with a deliberate short pause after each repaint (which you might have already done) to avoid super fast jittering confusing a student's path to understanding loops or the speed of computations allowing them to hide bugs in a string of instructions that don't have one of these wait commands or "critical points" in execution to force a repaint to help them understand the current state.
- netr0ute 4y ago
  Time to make a fork and use that for teaching instead
  - Wowfunhappy 4y ago
    I’d like to! Scratch’s backend is closed source. The open source version lets you save and load projects locally, but that’s a nonstarter for my classes, where most students work on different computers each day. I did have some success last weekend getting my fork to send a project’s data to a Cloudflare worker (where I can store it via Workers KV), but past that point I feel a bit stuck. None of this code is documented and I don’t have any backend experience. I think I need some sort of actual account and login system so that students can access all of their past projects. I'll probably keep poking at it, I'm just not sure I'll get anywhere. Other prominent forks such as Turbowarp don’t have cloud saving either, and now I think I understand why. It’s kind of frustrating tbqh. Scratch isn’t a good open source project if it’s centralized around a single host. I expect this of corporations who ultimately need to cultivate a customer base, but Scratch is an academic initiative from a prominent university. I understand why the backend is closed source, but I wish they provided clear documentation on how to hook it up to something else. (I also realize that like everyone in academia, they're probably understaffed and overworked, and I really do respect the tool they've built.)