Scratch is right now my 6yo's favorite toy. It beats the Lego robot because you don't have to worry about having the right parts and you can concentrate on the "fun parts," that is programming.
What really amazes me was how different the progression looked from what I was expecting. The move from "the dinosaur moves and that is fun" to fully fleshed mini games took me by surprise. No linearity there.
What I really appreciate about Scratch is how you can use the system without having to understand big parts of it. For example, one of the most complicated parts is the sprite editor (which does both vector and raster graphics). However, there's a huge library of sprites, so it's not a problem. You'll only have to learn the editor when your ambitions grow and you want custom sprites.
Another curious thing is that Scratch encourages concurrent code right off the bat (every script runs in their own thread). My son is coming up with rather elegant patterns which are nevertheless quite different from my intuition, like controlling the sprite's horizontal and vertical movement in separate scripts – which actually gives you easier to understand code.
Finally, there's a social aspect – discovering programs written by other kids and analyzing their code, and remixing them for your own projects. My son is a great fan of "Kimberly from Canada" who did a lot of "cook your own pizza" type of games, which have been a big inspiration.
As someone who has started programming at age 8, I find Scratch inadequate. It may teach kids how to code, but it doesn't teach coding.
There is something in writing every letter of a command when you are a kid.
There is something that gets born inside when you write and execute this for the first time:
10 PRINT "HELLO"
20 GOTO 10
RUN
My kid is 8 now and I plan to introduce her to an online C64 emulator and BASIC. If it does not stick, there is nothing that Scratch will be able to do. https://floooh.github.io/tiny8bit/c64.html
We use Scratch at Girls Who Code. Kids in the class are 9–12 or so.
I'm not the one who decided to use Scratch, but from observing the kids, one huge reason to use it is that most of the students can't type. If they want a character to say something, they use one finger to type out the sentence letter by letter, very slowly.
If they had to type everything, I don't think the class would work.
I politely disagree... My first programming was using the scaffolding of game engines. After a few years of those kinds of toys was I exposed to C, where I only knew how to use ASCII printed to the screen as output.
For a while, I used both the game engine and C. There were many ideas I wanted to try, that I could simply execute faster with the majority of the engine already in place. Exposure to C let me do things the game engine didn't support, but at the cost of losing graphics.
If your kid doesn't like C64... it doesn't mean "there is nothing that scratch will be able to do". Scratch supports graphics, sound, and more. C64 supports, at best, blocky graphics with ~16 total colors. And even then, the nuances of sprite limits, etc... It can get in the way.
Kids like games. Don't underestimate the value of graphics and sound support as a motivating factor.
No, just intuitevely. Hard to imagine becoming a great cook by pointing and clicking. Or a great pianist by pointing and clicking. A big part of what makes us human is what continous practice does to our brains.
Have to agree with this. I find that Scratch removes the dangers and perils of programming for any level, which, unfortunately, are the parts that you learn the most from.
Think about when you began to code. You tried printing 'Hello World' and that was good. Then you tried doing some more, and quickly ran into some trouble. At this crucial point, is where you are bound to learn the most. Troubleshooting is part and parcel of the experience. People need need to experience those painful points to grow, even young programmers.
That is thinking like an adult, though. First, hook kids on the joy of creating something interactive THEN they can develop the rigor to improve and learn more so they can do more. But if they start by hunting for missing semicolons they aren't going to want to bother continuing. Typing and syntax aren't programming anyway, just the most common input method.
I started coding by copying BASIC programs out of magazine (the olden days) and it was excruciating as a child limited by attention and focus. I never really learned anything about why things worked or didn't until much older. Slapping things together for fun and extending things to try new ideas seems way more effective to me.
Feel like you're taking your own experience and extrapolating. Assuming that in order to program is must be this gauntlet of difficulty one must overcome in order to be a true programmer.
Many people may give up when they encounter this trouble, but it doesn't mean they can't program eventually. Scratch may give them the tools they need to see what programming can do, then moving on from there.
The kids in my class run into all sorts of standard programming problems.
Two girls was creating a program where multiple characters had a conversation. Each character paused a set amount of time before saying its next line, and because the pauses weren't timed correctly, the characters kept talking over each other.
We draw a timeline together so the students could understand what was going on. The kids realized that every time one character was adjusted, every other character's code needed updates to match, and that this would get increasingly complicated as more lines of dialogue were added.
We talked through adjustments that could be made to lower the complexity. I suggested that when one character finishes speaking, it should "broadcast" a signal that it's the next character's turn. I don't remember if they actually refactored it, but they understood the problem-space and tradeoff.
You mean like how toy cars remove the dangers and perils of driving an actual car? Or how plastic cutlery removes the dangers and perils of sharp steel cutlery?
I've personally never been a fan of drag/drop puzzle-piece coding things like Scratch for teaching programming to kids. It just seems like it's sending them down this dead end path.
It took me a long time to find something better, and I've finally settled on Pico-8. It's the perfect combination of a simplified language that you have to actually type out in a stripped down editor, but with built in sprite and sound-effect tools and game loop methods that you can use to quickly get up and running with an actual 2d game.
It gets right to the heart of the great learning machines from the 80s (Apple ][, C64, TRS-80, Atari 400), but somehow fills in all the bits we've nostalgically romanticized over that would have made those machines a bad choice for kids today. Definitely check it out if you're thinking of getting your kids into programming:
It's not a dead end path, it's not far from how Unity works (of course you may consider Unity a dead end path).
I think your stance is needlessly puritan. At some point, the program has to actually do something and put it on the screen. Whether that is printing lines of text or moving a colorful sprite in some way is really not that different, except one is a lot more appealing to a young learner.
The purpose of the puzzle pieces is to prevent syntax errors, right? Do kids (or anyone, now that I consider the question) really need to deal with syntax errors?
Scratch is designed to encourage children, not discourage them. Syntax errors are the bane of learning to program for the first time.
As sibling comment indicates, it's also good to be able to code on a tablet, but I didn't think that would be as convincing to parent who seems opposed to graphical interfaces in general.
> Scratch literally has little graphical puzzle pieces that you drag around and dock together
You could build a "little graphical puzzle pieces" tool for any AST. You could even enable it to be driven with any combination of keypress input and mouse- or touch-based drag and drop. (Or even expose a text-based dump, for "free-form" editing by advanced users.)
QBasic's loss should be deeply mourned. Say what you will about it, it was almost the perfect beginner's environment. Simple, english-like syntax, good built-in documentation, support for graphics and sound right out of the box, and an IDE with a debugger.
Got QBasic in the 90's from a parent and bounced right off. Klick'n Play however consumed many hours. Or even batch files, if it meant I could get those Origin Systems games to run.
I got started with QBasic IDE. FreeBASIC was a nice replacement on the language/compiler side of things. I don't know if there's comparable IDE's. I found but haven't tried FBIDE.
As someone who was a beginner in QBasic, the docs left a _lot_ to be desired, especially the graphics ones. As a teenager, I had a hard time make heads or tails of them.
Granted, that isn't to say I wouldn't be able to navigate them pretty well today, but I distinctly remember struggling to understand large parts of QBasic back in the day
I do agree about Scratch.
I have starting using the web based Pyret with my 9 year old. We mirror the math and geometry problems and solve them in the browser environment. The simplicity to code, run, eval is key.
Not the OP, but I've had some good luck with teaching it to teenagers at the library.
By the time someone is a teenager, they likely have some experience doing algebra, which (I think) makes the idea of a "function" a lot easier to comprehend; variable substitutions and whatnot are kind of confusing to someone who isn't even used to seeing letters in math.
Really positive thus far. We'd done a bit of javascript before in the browser so he had some fundamentals already but it was always a bit distracting to have to deal with the additional HTML and CSS bits, as well as having to introduce the file system and an external editor.
But yeah, the 8 year old had a game up and running the first day, and the 5 year old picked up enough just watching to suggest code changes.
I set up an old laptop to boot straight into fullscreen pico8 so they can just open the machine and get moving. Just like my overly romanticized memories of myself at the same age.
I tried introducing a few "under-10s" to the joys of Pico-8
But it actually requires tons of patience if you really drill down into it
I made the fatal mistake of firing up a GameBoy emulator to show them examples of what they may create and naturally they became obsessed with classic pokemeon crystal instead ;)
It's obvious from your comments that you are going about educating your kids in the right way - a fun & interesting way that lets them explore. And the interaction with you is probably what they like best about what you are doing.
Thank you for posting this, I also volunteer in a local school running a Code Club. I would be very much interested to know how you handle differences in age group. I sometimes struggle as the group ranges in age from 4/5 yo to 11 yo. Finding suitable material that can be approachable for all is nigh on impossible and being only one individual I do not have the capacity to have multiple courses running in the same hour.
The main challenge is students who can't read yet vs. those who can. In an after-school elementary school coding club I did a while back, I mainly used https://code.org/
The kids also really liked Lightbot. Unfortunately, the web version uses Flash which means it won't run nowadays on most computers. There are apps though, including a LightBotJr version for 4+.
The first time I had this course, the kids were between 8 and 10. The differences in cognitive behaviour were minimal. Just some of them were a little bit slower than the others, but at the end they helped each other and everyone was finished at time. I see, 4/5yrs would be much trickier.
For our next course it will be a little bit more "diverse". The oldest application is 14, and some of the former kids are coming again. So it will be the whole spectrum 8-14.
I will see in the first lessons how I can separate them or offer different materials.
This time I'll offer some intro to Python. Maybe, one or the other will then grab this path.
I admit preparation of the materials was quit time consuming... more as I thought in the beginning it would be. But for the second course, I have already a bunch of prepared stuff.
Wow that is a giant difference, especially in cognitive capacity. I.e. by 11 you should be able to understand more or less anything (i.e. including abstraction, recursion, e.t.c) ... but a 5 yo might just be comprehending the number-symbol/object-count correspondence.
you could try to approach with a single theme? I.e. I heard from talk by Felienne Hermans, that her code club used alot of sprites/images from the Donald Duck comics, as everybody was reading that, and then you could scale by ability?
I.e. younger kids could do just animations, older kids interactions?
>>> with this individualization I was flabbergasted a few times
Don't be! Kids are digital natives. And given programming tools designed specifically for K-12 they will produce useful programs. Operational applications beyond mere Roblox zombie shooters to manage their increasingly complex young lives ;)
I was working with AWS last summer with the goal of creating a cloud based IDE for ChromeOS. And I feel the current barrier is programming languages and paradigms as they exist today. Visual logic languages and blocks programming, dating back to Turtle Graphics and the original Logo designs from 1967 by Wally Feurzeig, Seymour Papert, and Cynthia Solomon have been used for generations. But I could see the next evolution as being voice based. In the era of Siri and Alexa, perhaps kids should be composing blocks as parameterized tasks spoken in natural human langauge. This is a big undertaking and more than I can handle at the moment, but I have been experimenting with a Google Nest Mini, and even simple trivia games or joke applications can amuse kids for hours. "Hey Google, what's the weather like on Mars today" opens a portal to infinite curiosity and exploration about the cosmos we live in.
The other era of promise I've seen is the engagement around simple physics games and simulations. Think of the level design mode in 2D collision games like "Crush the Castle" or "Angry Birds". With the amount of available energy kids have they are able to build epic structures and take delight in watching them fracture unpredictably.
Bottom line is these games and interfaces have to get much better. And that requires targeted investment as well as vision
I had a very similar experience last month teaching elementary kids Scratch.
I did a group activity building a few games. Then I challenged kids to create there own versions. Some of the older elementary kids really did a great job making their own games. They want me to come back in to teach more.
I have been working on an online course for kids on the side since Summer. They definitely enjoy the creativity aspects.
Anyone know why Scratch lite is so limited on the iOS? My 2 year old has nearly mastered all the features but I'm hesitant to let him loose on a laptop.
With Scratch 3.0 you can run the full web based Scratch on any iOS device, although I doubt it would be a good experience on anything other than an iPad.
What really amazes me was how different the progression looked from what I was expecting. The move from "the dinosaur moves and that is fun" to fully fleshed mini games took me by surprise. No linearity there.
What I really appreciate about Scratch is how you can use the system without having to understand big parts of it. For example, one of the most complicated parts is the sprite editor (which does both vector and raster graphics). However, there's a huge library of sprites, so it's not a problem. You'll only have to learn the editor when your ambitions grow and you want custom sprites.
Another curious thing is that Scratch encourages concurrent code right off the bat (every script runs in their own thread). My son is coming up with rather elegant patterns which are nevertheless quite different from my intuition, like controlling the sprite's horizontal and vertical movement in separate scripts – which actually gives you easier to understand code.
Finally, there's a social aspect – discovering programs written by other kids and analyzing their code, and remixing them for your own projects. My son is a great fan of "Kimberly from Canada" who did a lot of "cook your own pizza" type of games, which have been a big inspiration.