Linux Kernel Module written in Scratch (a visual programming language for kids) | Hacker News Reader

Linux Kernel Module written in Scratch (a visual programming language for kids)

lunduke.substack.com

257 pointsisp38 comments

This supports a very tiny subset of Scratch - basic control flow, variable assignment, and arithmetic operators. It's also an "incorrect" implementation, because Scratch arithmetic operators are supposed act on double-precision floats.

"Real" Scratch is much harder to compile to a native language, firstly because Scratch has a very weird concurrency model (unofficially documented here [1]), and secondly because it has weird dynamic type conversion rules, much like JavaScript. E.g. the scratch expression (("0x1" join "4") + (2)) would evaluate to 22.

I'm just being pedantic though, this is still a cool project.

[1] "Scratch and its inner workings" https://docs.google.com/document/d/16SFYkk9dWpMhYaZNnLTE_kTm...

Author here - Yes I am somewhat aware of these issues and I am working on a better output with a runtime to do stuff in a less cursed manner. Note that the freestanding subset of it is just a joke and shouldn't be taken seriously. I hope that the hosted one will be more complete and true to Scratch's official implementation.

> shouldn't be taken seriously

Are you trying to supply material for future Linux Sucks lectures? :)

Edit: I see that Lunduke agrees it is awesome.

(Outside of DSLs, Scratch impresses me as the one visual language to invest confidence in.)

That document you linked is amazing! I don't know much scratch but my son has gotten deep into it building games, and he's frequently asking me questions about how it works and I'm always forced to speculate. This is fascinating indeed. Thank you!

I have heard scratch described as a 'Domain Specific Language for writing Race Conditions'

It's certainly easy to end up with race conditions in Scratch, but I don't think it's any easier than in something like Javascript?

The kernel does not save the state of the math coprocessor when context switching. This means floats are off-limits in the kernel.

kernel_fpu_begin() / kernel_fpu_end()

My 11yo likes Scratch.

This might be a good gateway drug.

It was mine (not because of this though)! Although in my case I learned "an actual programming language" since my parents discouraged Scratch as an abject waste of time, so I learned Java out of spite. I was hooked onto making video game recreations in Scratch.

I'm glad it worked out for you since you learned Java, but hearing stuff like this makes me sad. Scratch needs a "make me feel like an adult" visual setting which darkens the colors or something.

I was actually showing Scratch to an adult non-programmer friend last weekend. She was very impressed, saying that if she ever wanted to learn coding, she thought Scratch would be a great tool for her.

Programming in Scratch is programming. The only real difference is that instead of typing instructions, Scratch users drag them out from a list of options. I think we would all agree that memorizing syntax isn't a major part of programming, but it's a major source of cognitive load for beginners. Scratch removes that barrier.

My company sometimes describes Scratch as "learning to talk before learning to spell." I think that's a great analogy.

Tbf, I'm not denying that it is a programming language, but rather that I was discouraged from using it because my parents did not view it as programming.

Right, your parents were the ones making that assertion (implicitly if not explicitly).

Why did your parents think Scratch was a waste of time? Did they not want you to program or did they have another language in mind?

They also know how to program and never started on Scratch so their definition of a programming language is different.

Learned Game Maker around 10. It had a similar drag-and-drop interface.

Can confirm- excellent gateway drug

GitHub:

- https://github.com/scratchnative/scratchnative

- https://github.com/scratchnative/scratch-linux-modules

In other words, Scratch can interface with C code.

Looking the repos to refute your snark, but you appear to be correct. The example given seems to be the thinnest of wrappers around the kernel C API and translates directly into the equivalent C for compilation. Does not seem like native scratch code in the kernel a la Rust.

I was looking at the repos too, not only at the linux module, but the whole "OS". Hoping for some cool scratch stuff.....but....it's just minimal wrappers.

As an aside, I think scratch is great, it's definitely not just for kids, I think it's great for anyone learning programming

A colleague of mine completed the first half of advent of code just using Scratch. She pushed it to it's absolute limits.

More like "Scratch can generate some C code"

So, time to start using scratch in a professional context. I know some BA's who'll have a lot of fun.

I'd say visual programming languages were first created to be used in a professional context. (Think BPEL and even earlier incarnations.)

The design workshop with a Surface on the wall is going to be tons of lego-colored fun !

"finally spaghetti code that look like spaghetti"

The blog says C++ though. Forget everything about kids and jigsaw UI, ++ in the kernel, this ist huge! ;)

There is also a C codegen available, still WIP though.

Basic on the commodore 64. That's how I learned it. You turn the computer on, and that's pretty much all you can do. Learning to program now, is like, sure I get that it's important and all, but why? why would I?

We had it so good.

Needing to program specifically? No reason. The computational and analytical thinking skills that come with it are generally useful though.

I also never again written a poem analysis or held a talk about labour movements in the Weimar Republic. Did I practice important skills in school? I'd say yes.

That is kind of the point. Programming has become the same kind of useful skill as writing a poem analysis. It's easy to explain that it is useful and important. But I don't get across why you would want it.

Even though they are using a minimal and compileable version of Scratch, I think this is so cool.

In the 1980s, I had a Lisp Machine and except for the microcode it was Lisp for everything. Amazing to have an OS and all tools written in one high productivity language.

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...Wowfunha...

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.

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.

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.

Time to make a fork and use that for teaching instead

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.)

Reply on news.ycombinator.com