Kids do program – Experiences from the course
sar3.ch
sar3.ch
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.
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
Those are some pretty strong words. Did you do any research on this topic?
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.
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.
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.
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.
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.
It's weird how you need to rewire your brain for it.
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.
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:
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 ;)
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.
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.
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.
Beyond that it's pretty similar to the thing I (and you) recommend.
The problem is not syntax, the problem is that they're bad at typing on a keyboard.
I suspect it's mostly because the keyboard is too big and stiff...
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.
1. Prevent syntax errors.
2. Remove the need to type on a keyboard.
3. Remove the need to memorize basic commands.
The kids will eventually need to learn #2, but I think it's great that they can do programming in the interim.
#3 will start to come naturally once you've dragged enough if-else blocks in Scratch. Scratch is an on-ramp.
I will point out btw that Scratch is turing-complete.
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.)
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
For others looking for text-based programming for kids, there is SmallBasic https://smallbasic-publicwebsite.azurewebsites.net/
And another blocky course is https://studio.code.org/s/express-2019 (You can even toggle to show javascript.)
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?
If Scratch is too advanced for the youngest of kids, try ScratchJr: http://www.scratchjr.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+.
Here's a google doc with several other elementary school coding & robotics resources, although I haven't updated it in a while: https://docs.google.com/document/d/1r1b2CM1uTdST47IbWa7zlZYm...
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.
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 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.