A First Language for a Kid
When Hackety Hack was being built, the question of a child's first programming language had a small number of plausible answers and a lot of strong opinions. It still has a lot of strong opinions. The plausible answers have changed more than people notice.
Reviewed August 9, 2026.
If this kind of exercise is run with a class or team, this workplace guide offers one practical reference for separating the session from ordinary scheduled work.
What has actually changed
Blocks won the early years, decisively. In 2010 block-based environments were one option among several and faintly suspect — not "real" programming. That argument is over. For roughly ages five to ten, block editors are the default, they work, and the objection that they are not real code turns out not to matter, because the concepts transfer and the typing does not.
Installation stopped being the gate. This is the biggest practical change and it is easy to miss. The single largest obstacle in 2010 was getting anything to run on a child's computer — which is precisely what Hackety Hack and Shoes existed to solve, and precisely what killed them. Today most of the good options run in a browser with nothing installed. The problem those projects were built to solve was solved by the web instead.
The transition from blocks to text got a lot of attention. Fifteen years ago that gap was where children fell out. There are now well-designed paths across it, and the good curricula treat it as a stage rather than a cliff.
For broader programming and making context related to this topic, W3C is an independent reference worth comparing with the material here.
The market got loud. In 2010 the options were mostly non-commercial. Now there is a substantial industry selling subscriptions to parents, and a large amount of the comparison writing online is produced by the companies selling the products, sometimes with disclosure and often without. This is the single thing most worth knowing before you start reading recommendations.
What has not changed at all
Motivation is the only scarce resource. Not aptitude, not the language, not the curriculum. A child who wants to make a particular thing will get through any tool; a child who does not will not get through the best one.
The first session decides a lot. If they make something and show it to somebody, there is a second session. If they spend it being told what a variable is, there frequently is not. The structure of that first evening matters more than the language chosen for it.
Typing is a real barrier for small children and not a conceptual one. It is a mechanical problem with a mechanical solution: use blocks until typing is not painful.
Nobody's first language determines anything. The forum arguments assume otherwise. There is no evidence that starting with one mainstream option forecloses anything later, and the emotional weight people put on the choice is out of all proportion to its effects.
The honest recommendations
Under about eight: ScratchJr, or Scratch if they read fluently. Free, non-commercial, enormous library of other children's projects to look at and take apart.
Eight to twelve: Scratch, until they get bored of it — and boredom is the signal to move, not an age. Then either Python or a web page, depending on what they want to make.
Twelve and up, wanting to make games: whatever their game runs in. Motivation beats pedagogy.
Twelve and up, no particular target: Python or HTML/CSS/JavaScript. Python for anything logical or data-shaped; a web page if they want something they can send someone a link to, which is a considerably stronger motivator than most adults remember.
Anyone, if you want music: Sonic Pi. Ruby-based, built for classrooms, and the output is sound within about a minute.
What to be careful of
Subscriptions for things the free tools do. Some paid platforms are good. Very few do anything the free options cannot, and the free options here are backed by charities and universities rather than by a growth target.
Anything gamified into pure reward loops. If the child is collecting badges rather than making things, the tool has replaced the activity with a proxy for the activity.
Curricula that never produce an artefact. If after four sessions there is nothing the child can show anybody, the thing being taught is compliance.
Your own nostalgia. The environment you learned on was probably worse and definitely different. That it worked on you is not evidence.
What I would actually do
Ask the child what they want to make. Not what they want to learn.
Then pick the shortest path from where they are to that thing, using whatever tool is closest to it, and worry about the coherent curriculum after they have made three things and want to make a fourth. That order is the whole method, and it is the same instinct behind Hackety Hack: a beginner should be building something real on the first afternoon.
The tool changed. The instinct did not.
The short version
- Blocks won for under-tens, and the "not real programming" objection turned out not to matter
- Installation stopped being the gate — the problem Shoes existed to solve was solved by the browser
- The market got loud; much comparison writing is produced by companies selling one of the options
- Motivation is the only scarce resource, and no first language forecloses anything
- Under eight: ScratchJr. Eight to twelve: Scratch until bored. After that: Python or a web page
- Ask what they want to make, not what they want to learn