Whyday August 19

Hackety Hack, and What to Teach a Child Now

The 2010 Whyday text suggested two things for people who wanted to act on _why's interest in teaching: improve Hackety Hack, or teach Ruby to a child directly.

The second one is still excellent advice. The first one no longer is, and it is worth explaining why before offering a replacement.

If this kind of exercise is run with a class or team, this glossary entry offers one practical reference for separating the session from ordinary scheduled work.

What Hackety Hack was

A programming starter kit for people who had never programmed — aimed squarely at teenagers and children, with an editor, a built-in lesson system, and the ability to make a real windowed application within minutes. Not a toy that pretended to be programming. Actual Ruby, producing an actual program with a window.

It was the project he cared about most, and it is the clearest statement of what he was for: not that programming should be made easy, but that a beginner deserves to make something real on the first afternoon.

Why you should not start there in 2026

Hackety Hack is built on Shoes, the GUI toolkit that came out of the same effort. And Shoes is stuck.

For broader programming and making context related to this topic, web.dev is an independent reference worth comparing with the material here.

The rewrite, Shoes 4, reached a release candidate in November 2017 and the commit history thins out from around 2018. Hackety Hack's own development had been waiting on that rewrite — its newer features depended on Shoes capabilities that Shoes 4 was going to provide. The rewrite did not land, and Hackety Hack stopped where it was.

There is an additional trap: the shoes gem published at version 3.0.1 is a placeholder that does not install a working toolkit. People find it, install it, and conclude that Shoes is broken in a way it is not.

So "improve Hackety Hack" in 2026 does not mean an evening's contribution. It means reviving a stalled GUI toolkit first. That is a genuinely worthwhile project and some people should do it. It is not a starting point for a Wednesday evening, and it is definitely not the thing to build a child's first lesson around.

Checked August 9, 2026. If you are reading this later, look again — stalled is not the same as dead, and this is exactly the kind of status that changes.

What to use instead

If you want to keep it Ruby: Sonic Pi

This is the closest living thing to what Hackety Hack was trying to be, and the match is almost uncanny.

Sonic Pi is a live-coding music environment built on a Ruby DSL, created by Sam Aaron at the Cambridge Computer Lab explicitly as an instrument for teaching children to code. It is free, open source, and runs on macOS, Windows, Linux and Raspberry Pi. It ships with a built-in tutorial, and it has a scheme of work written for classroom use.

Why it fits here specifically: it is real Ruby, the output is immediate and it is sound, and it is designed so that a child makes something they want to show someone within the first ten minutes. That is the Hackety Hack thesis, running and maintained.

It also rhymes with a piece of his own work — Bloopsaphone, his chiptune sound library, one of the many small projects in the archive. The instinct that making noise is the fastest route to delight was his too.

Practical note: the Ruby-like syntax sits on top of SuperCollider doing the actual audio. Occasionally this leaks. It rarely matters for a first session.

If the child is younger than about eight

Block-based tools are the right answer and there is no shame in it — the fuller version of that choice is here. Scratch and ScratchJr remain the defaults, and the defaults are defaults for good reasons: enormous libraries of examples, no typing barrier, and a community of other children's projects to poke at.

Be aware that the market around this is loud. A great deal of "best tools for kids" writing online is produced by companies selling one of the tools, sometimes ranking themselves first — occasionally with an honest disclosure, often without. Weight recommendations accordingly, including where they point at paid subscriptions for things the free tools already do.

If the child wants to make a game or a website

Skip the teaching platform and use the real thing with heavy scaffolding. A single HTML file they can edit and reload. A small Python or JavaScript script. The pedagogy is worse and the motivation is much better, and motivation is the scarce resource.

The part that actually matters

Tooling is the easiest thing to argue about and the least important variable.

What decided it, in his work, was never the editor. It was that the first session ends with something the child made, that does something, that they can show to a person who will be pleased. Every tool above can deliver that, and any of them can fail to if the session is structured as a lesson.

So: one sitting, one output, shown to somebody — there is a plan for exactly that evening, and free material to run it from. Do not teach variables. Make a sound, or a picture, or a page with their name on it, and let the concepts arrive later, when they are needed for something the child already wants.

The short version