I've always been suspicious of the looks-like-an-animal-with-a-name-and-a-smiley-face-I'm-a-grown-up-and-this-is-what-kids-like approach. I remember one of the coolest things about the apple II was that you could 'poke' the right memory address and get the speaker to click. That was magic when I was 12 and it didn't need a friendly name and a stupid grin. Until they're old enough for K&R (12?, 13?, 14?), maybe they should do something else... or maybe anything else...
100% agree. I think the best way to learn to code is to... write a lot of code. I'd bet that's how most of the self-taught people here learned.
Shameless plug: in Hack Club (https://github.com/hackclub/hackclub), our approach to teaching is to not actually "teach". Instead, we have a bunch of open-source workshops (https://workshops.hackclub.com) that walk high schoolers through the process of building a real thing (using real code), like a website or game. We don't expect them to understand everything that's happening. In fact, we expect learners to not understand 90% of what's happening -- our goal is to get people excited about hacking and have most of the learning happen when they're googling to build their own projects.
I think they have their place, and they probably have a lot of evolving left to do, but I think they shouldn't be the sole focus of programming for kids.
I have taught kids as young as eight JavaScript. They really take to it. JavaScript is not an ideal language for teaching beginners, but the availability means you can do it anywhere.
I made a little library to provide easy to use functions and start with programs of the sort I would have written in basic when I was young.
You're conflating different audiences. Sure, cutesy stuff is counter-productive for a 12 year old, and probably even most 9 year olds.
But at 4 years old my kid was already applying loops and subroutines in LightBot (and later Robot Turtles). At that age kids can already get the thrill of command and begin to play with abstractions, if you give them a domain of discourse that's non-textual.
Agreed. There is evidence that capability for true abstract reasoning does not properly develop until 12 or so, and that students who are taught basically no math before then catch up to their peers in a matter of years anyways. Before a certain point it is just wasted, probably.
I strongly agree. Kids are smarter and much more adaptable than the people developing this stuff seem to think. I don't understand why we aren't just exposing them to real programming languages from a very young age, like their native tongue.
Visual programming system such as Scratch eliminates spelling as a source of frustration for younger kids and especially those whose native tongue is not english (on which the syntax of most programming languages is based on).
The logic of programming however, exposes the developer to exactly the same mental processes as programming with a typed language would. I've watched my son programming Scratch and I can guarantee even the typical the bugs are there in same form as in C++. "Why is this not working - oh, I need to initialize this variable not here but inside this loop" and so on.
spelling as a problem is eliminated, but sticking together blocks also has its limits - with scratch the code gets complicated, when it does it becomes quite hard to drag and drop out of this mess - i found it hard to manipulate a structure of blocks with more than two levels of nesting.
I don't think when discussing young kids the main motivator should be to teach them to program. Rather, as a parent I like to expose my kids to as many different ways of thinking and expressing one self as possible.
"I remember one of the coolest things about the apple II was that you could 'poke' the right memory address and get the speaker to click. "
My 8 year old enjoys drawing characters in Scratch and then programming game and movement logic for them. Personally, I fail to see which experience has more objective value. Personal experiences such as you describe are mystical in the way that there is no rational way to share them with anyone else or make them understand it unless they've felt it themselves.
I don't really think there is a "wrong way" to have fun with a computer.
I think it's incorrect to view kids programming environments as a part of vocational programming curriculum. Rather, they are yet one more platform where kids can be creative and enjoy building things for themselves, like with Legos.
I was certainly in a similar boat (though a later generation of computers) whereby I found around age 9 that "poking" at a computer (either plugging random things in, or clicking random buttons or keys) enough yielded some interesting/mildly entertaining results. Of course, many times, these results ended with being grounded for breaking something, but nonetheless, the endless possibilities of random keystrokes and mouse clicks seemed to exude some kind of strange primitive allure.
That is also a very decent approach in my opinion. I'm not aware of any studies on ideal age for programming or other skills that correlate to learning it better but I suspect it can't hurt to wait a bit and not rush it (it's very likely to be a hugely individual thing).
Since I have recently ventured into learning how to draw (I am pretty horrible at it) my mind is kind of blown at how much that influences my general thinking and thought modes. Maybe identify these general activities and nurture them first before jumping into the actual programming (logic, drawing, thinking in processes and parallel etc.).
Why is BASIC totally left out? An entire generation was inspired by power-on basic in C64 and other platforms. More than just "inspired"... Some huge amount of today's technology wouldn't exist otherwise.
I know I'm stuck in the past, but that's what I want for my kids. Flip open the laptop and boom, theres my programming environment, except now with easier graphics/sound APIs.
Anyone know how to get this, without buying a c64 + CRT monitor?
It's really hard to do something like that with kids today. They have so many options now between consoles, iPads, etc. There's way too much instant gratification. You're never again going to see a generation that has the patience to type in the source code to a game published in a magazine.
People have been saying "you're never again going to see a generation that has the patience to X" for generations, when really X is just no longer a thing anyone wants to do.
When was the last time you typed in source code from a magazine? These days we all expect software to be more complex than what you can fit on a printed page. People have patience for the things they find exciting: nobody is excited by dinky type-in games any more.
Untrue, at least in the case of my 9 year old. He loves writing Javascript "apps" from bitsbox (bitsbox.com). I learned by poke'ing on an Apple ][ because that was the tech of the day. Apps are the tech of the day for kids and he loves seeing the things he can create.
I have a little side project in this vein: http://akkartik.name/post/mu (apologies for the spam; I already posted my link elsewhere in this thread). No graphics or sound yet, unfortunately. I've been using it to teach long-distance, so the way we work is by running it on a VPS over a shared tmux. So it's completely text-mode. But in text mode you can do a lot with just raw cursor mode and 256 foreground/background colors. One of my students just built a card game with it.
(Another interesting feature of it: the programming environment is itself built in the Basic-like language. So there's a large example app that comes with the repo, along with a few small ones.)
Most platforms don't have a power-on equivalent, but BASIC derivatives with better sound/graphics/etc. APIs [0] are widely available (the particular selection will depend on platform, e.g., RFO-BASIC for Android.)
[*] well, maybe not better in all cases; for lots of simple things, some of the 1980s home computer BASICs had pretty good simple sound synthesis APIs.
One of the great things about C64 BASIC was that it didn't do too much hand holding. It had syntactic simplicity, but you had to deal with the underlying machine. Want to draw a circle? There was no "circle" command, you had do the math and flip bits with peeks & pokes & apply Boolean logic to retrieved values.
As a kid ~12 or so programming the C64, that did a few things that I think languages like those being presented here miss: 1) the computer didn't talk down to me as "being for kids", yet was simple enough to get me started without large amounts of previous technological background required; 2) the computer had more advanced capabilities that I could tackle as I gained experience (i.e. the aforementioned having to deal with memory manipulation); 3) Because it wasn't built for me (a kid), it didn't have to pretend to keep me entertained... there was a mystery to it all that as I progressed, I became more ensconced in deeper levels of knowledge that was earned, not given.
Sure I wasn't doing brain surgery, or even software engineering, but those early lessons gave me the fundamentals of why certain things mattered and how to solve problems that weren't child proofed.
Have a look at Kano on the raspberry-Pi even if you don't buy the kit you can download the image. It is a really well put together package which I can't recommend highly enough.
http://blog.kano.me
Terry Davis (creator) likens it to the C64, though you're writing in CPP/ASM:
"The vision for TempleOS, however, is a modern, 64-bit
Commodore 64. The C64 was a non-networked, home computer
mostly used for games. It trained my generation how to
program because it was wide open, completely hackable.
The games were not multimedia works of art, but generated
by non-artist."
That is awesome. I always joked with my wife that if we ever get our kid a computer early on, it wouldn't be an iPad, etc. that I'd figure out how to only give him exactly the sort of thing I had when I was a kid (a C64) and if figured that out, he'd be OK. The joke now becomes reality! :-P
There's also the FUZE and FUZE BASIC, a retro-y keyboard case and BASIC dialect for the Pi. https://www.fuze.co.uk/
I would also second the suggestion of the PICO-8, which is a Lua-based retro virtual console complete with its own built-in dev environment. http://www.lexaloffle.com/pico-8.php
I've been building a very simple development "portable" PC using a 7" TFT display, wireless keyboard, and a Raspberry Pi. At the moment, it just boots into a Linux login shell, but you can program it to boot into a desktop environment if you want (and if you have the power luxuries!). Of course, the Linux environment may be too much for kids, but this might be close to what you want. Also a decent overall price: altogether so far, I've paid a little less than $100 for this whole setup ($30 for the display, $35 for the RPi, $25 for the keyboard), though you could get it for much cheaper using a Raspberry Pi Zero ($5!) and a cheaper keyboard.
Get either FreeBASIC+IDE, BlitzMax, BlitzPlus, FnxBASIC, Browser BASIC or MonkeyX and place a shortcut to the program in the Startup folder on Windows.
What was it on the C64? I would have thought you would have had to write a program to do it. What is the command to spawn a zombie on the C64? Or to display a gif? Or to download data from an Internet service?
Having animals and colorful bricks is okay, so long as we're not in conflict with what is actually fun about what is being taught here...
Programming is fun because we can control the machine, and make it do things... magically, at our whim, with the right combination of instructions.
So compared to that, having a cat walk towards a barn seems like a completely irrelevant layer of entertainment forcefully tailored to the taste of the students, who at best are distracted from the real fun, or at worst presumed to be incapable of understanding why programming itself might be fun.
For all practical purposes HTML is a great place to start. Immediate output, can share it online, and it's easy. And easy to expand upon with CSS and Javascript and everything else. Also Processing is great for an art cs class. Not to mention both web development and computer graphics being two highly relevant skills in today's job market (thought that is thinking a bit ahead considering the ages here, but better relevant than sorry).
Have you programmed in scratch for any significant amount of time? I have, so have my kids, and as a CS prof (at a small non-engineering college) I encourage my students to do so too. Before age 10, almost entirely on their own, my kids discovered ideas like abstraction (writing custom blocks), recursion, data representation (e.g. encoding/decoding pairs, structs and lists into arbitrary-precision integers), asynchronous vs. synchronous functions, performance tuning, 3d perspective graphics, and race conditions. At bedtime it's not unusual for them to ask about, say, what happens if you do recursion without a base case, or wonder whether you could simulate the scratch language within scratch itself.
All of these things are fundamental CS concepts, and they seem to grasp these at a much deeper level than I did at that age, and better than most of my college students. Yes, they also do some python, html/css, a little java, a bit of javascript. And those all have their place, and they like making websites. But the scratch infrastructure is fantastic. Good learning curve. Just enough language power to do amazing things (threads, fork, async notifications, custom blocks, cloud variables for multiplayer online). Instant publishing. Great community. Fantastic programmers (hi Griffpatch!) putting out incredibly clever programs to admire.
So all this is to say that it is unfair to dismiss scratch as "a cat walks towards a barn".
I was trying to be careful not to do that, and you'll see that I didn't. So long as we're not in conflict it's okay, and certainly Scratch is more than cats and barns.
But my point remains that cats and barns could be interpreted as "fun because they're kids" since no CS prof in their right mind would teach students that way at, say, MIT. Maybe robots.
The problem isn't with teachers who teach the magic of computers with cats and barns. It's with the teachers who confuse the fun with cats and barns and underplay the real magic, which then leads the students to be confused and unimpressed as well.
Whenever I saw educational games as a child I'd immediately sense the "adults intent to entertain" through boring characters and ugly art. Now, that isn't to discredit their effort, but when you're a kid obsessed with Super Mario Brothers, it's tough competition. Needless to say, educational NES/Famicon games did not fair well on the market. Everyone loved Mario.
However, bad teachers will always be with us, and won't start teaching the magic of computers just because you give them a c64 or basic. They'll just make kids write endless employee pay calculator programs and other drudgery.
I do agree with your general sentiment about the transparency of "intent to entertain". But I really don't see it with scratch. There's a silly cat on the front page, and comic-book logos. But 5 minutes after first being introduced to that, kids are already looking at Griffpatch's latest multi-player cloud-based platformer, or the cool 3d render program, or the interactive fractal, or the simulated ice-cream shop factory, then 5 minutes later they are staring at code trying to figure out how they did it so they can make their own. Really. On the frontpage right now, the top-featured studio (i.e. a collective hacking club) is called "Lindenmayer Systems!" [1], showing their latest L-system fractal fern generator [2]. I really don't see a lot of "forcefully tailored" entertainment here. Just a site filled with projects made by kids and adults on a huge range of topics, from lipstick, fashion and silly greeting cards, to mathematical and engineering.
Incidentally, I'm assuming you know scratch was designed at MIT, and many aspects were deliberately designed to teach advanced concepts. And that it has, in fact, been used in college classrooms (Harvard [2], others I believe). Still, I contend that my kids with no formal CS education have a far better concept of an abstract data type because of scratch sprites, and this has carried over very naturally to other languages (Java objects, smalltalk message passing, etc.).
Yes, made at MIT for kids, not students. Building Scratch was the assignment, and it was probably a lot of fun. I in no way wish to discredit the efforts of those who use and maintain Scratch.
The only meaningful point I might add would be that kids love to compete with adults. They want the real thing. Of course, most can't handle the real thing, so we give them what we think they can handle. Except, for the smart kids, the bar is always too low because it has to be adjusted for the averages. So they feel like they're being treated like kids, and that their intelligence is being undermined, and they may even feel discriminated against. Basically, they don't think of themselves as kids. We the adults think of them as kids. Not that they aren't kids of course, but we should never limit their intelligence based on what we think they can handle.
It's a shame modern video games are so complex and cinematic. To Scratch's credit, here is mario:
>they seem to grasp these at a much deeper level than I did at that age..
What real difference will it make in the future? I think none. Some one who understanding recursion when they were 10 will not end up much better programmer than someone who was exposed to it at 20, and have sufficient experience in using the concept. Same with other CS concepts.
The idea of making kids learn this sounds great, because it looks great when kids do stuff with computers. But it is not really giving them and advantage in the future.
Why do you think so? It's a common knowledge early start gives one an advantage in many disciplines: music, ballet, chess. Why are you so sure programming is so different?
I think those things are different. How many people in the world can create music like Beethoven or Mozart? How many people would have been able to beat Deep Blue in chess at that time? I can imagine there would be music that could only be rendered on a piano or violin, by only a hand full of people in the whole world.
In a similar manner, do you know a program that could only have been written by an 'expert' programmer, or only a hand full of expert programmers in the whole world? I don't think so.
The essence of what I am saying is that, programming is not a hard enough thing to waste those precious early years on.
Yes, I can think of programs that can only be designed and implemented by top 1% of programmers.
Regarding "programming is not a [...] thing to waste those precious early years on.", well, this is not something I'd like to argue about, just want to say that learning programming by a kid doesn't have to be (and, of course, shouldn't be) a 8h or more daily activity, like for a professional adult programmer. I think an hour per week of learning programming can be a valuable exercise in logical thinking, creativity and problem solving. It can easily be a lot of fun, too.
> I can think of programs that can only be designed and implemented by top 1% of programmers...
Interesting. Can you share some of those...?
EDIT: Oh, I just noticed that you said top 1% of all programmers. I was not talking about top 1%. I was talking about a handfull of them. Top 1% would be quite more than a hand full. But please share those programs anyway...
Scratch is more programming than HTML/CSS by far. It has control structures, functions, etc. Aside from the most obvious projects (games), we've used the Kinect for input and directly interfaced with hardware. We've solved a ton of Euler Project problems in scratch and created physics simulations. I'd be hard pressed to find something you can't do in scratch with enough creativity.
For kids, the biggest limiting factor is typing speed. With most languages, as soon as they can think faster than they can type, you hit a second roadblock of frustration where they are thinking too far ahead of what they're doing. Scratch really just abstracts boilerplate for things like showing a sprite and moving it into draggable blocks. The transition from Scratch to Python has historically been pretty easy since most of the kids understand the abstract concepts really well after 1-4 years of Scratch.
>So compared to that, having a cat walk towards a barn seems like a completely irrelevant layer of entertainment forcefully tailored to the taste of the students, who at best are distracted from the real fun, or at worst presumed to be incapable of understanding why programming itself might be fun.
The turtle/cat is a concrete place holder for abstractions like state and variables. Being able to to grasp algebraic variables and other high level abstractions is correlated with Piaget's formal operational stage of cognitive development which most children only begin entering in middle school. You probably could teach a 9 year old programming without these training wheels in the same sense that you could probably teach them algebra.
"Having animals and colorful bricks is okay, so long as we're not in conflict with what is actually fun about w
that is being taught here..."
The concept of 'fun' is highly personal. Surely you are not suggesting there is only one way to enjoy using a computer :)
"Programming is fun because we can control the machine, and make it do things... magically, at our whim, with the right combination of instructions."
I think you are creating a value statement that is not universally true. My son enjoys programming because he can draw himself a character and the program the character to respond to key presses. The machine between him and the program is irrelevant to him.
"draw himself a character and the program the character to respond to key presses."
Except, don't you see that that's him controlling the machine and making it do things magically at his whim with the right combination of instructions?
The statement I made may not be universal, but you provided an example, not a counterexample, which infers you may not have well understood the full scope of said statement.
And most certainly cats and barns is a stab at universal-as-possible fun. We may not be identical, but nor are we that different.
It is a perpetual puzzle to me why learning programming isn't considered to involve learning about functions. In my experience the hardest thing about programming is teaching people the facility of "uncoiling" in their heads the coiled representation of a loop or repeated calls of a function. That in turn requires as a prerequisite the ability to consider a function being called with multiple different inputs, and hold multiple possible situations as you build the function. Until you attack this, the hard problem of teaching programming, anything you come up with will only help learners with the first few hours of their learning. Which is invaluable, don't get me wrong. But what then? There's got to be something better than, "ok you're done with blocks and turtles, now go learn JavaScript."
Scratch has the concept of functions. They are also called blocks. Custom blocks which kids can create. The blocks can take parameters and are conceptually identical to functions.
I don't know about the other languages mentioned though.
I prepare curriculum for Grades 4 and 5 on Programming using Scratch and Flowcharts and teach kids to create blocks whenever they see that functionalities are getting repeated.
Kids tend to learn a little differently compared to adults. Adults tend to want to know the 'big picture' before they begin and tend to have different preconceptions based on what they've learnt earlier. Kids' learning is much more playful, motivated more by inquisitiveness and curiosity. They don't have the urge to prove anything to anyone, including themselves.
At those grades, their brains are very flexible and they can think of strange combinations and the ultimate goal of having a program solve a problem is not the aim. Even after many years, I find it hard to let go of trying to guide kids towards a goal, rather than keeping my mind open to new things that they are able to see just because they're not motivated the same way we as adults are.
That's true. Logo has functions too. But for all the innovation that has gone into making the notion of an instruction easy to learn, functions everywhere look the same. For example, why can't a function in Scratch change its shape based on the number of arguments?
When I learned programming it took me years to stop "ping-ponging" between bugs. I'd fix the most recently discovered bug, only to simultaneously break the second-most recently discovered bug. My students show the same behavior. That's a sure sign that just giving kids functions doesn't help them understand.
Your observations about the differences in learning strategies were useful, thanks.
I hope you don't mind me asking, but I would really appreciate if you could share the curriculum you have been working on, or if you could share you experience.
I am currently trying to do the same, so I would appreciate any form of help I can get.
As someone who started programming at a young age where using three meta keys on the ZX Spectrum was something my hands literally couldnt do... I say to all the people suggesting give kids a raw language interface, think about how accessible that interface really is. First you have to learn typing and unlike the spectrum you need to remember and learn most keywords. You are eliminating perfectly smart kids immediately. Because they have a massive barrier to the reward of programming. I remember using a pencil in my mouth to get the third meta on that keyboard. Fairly sure thats a health and safety nightmare. But the frequently used commands were single finger. As my desire to program increased the interface to my own goals got harder. I had the advantage distribution of my software to friends was trivial too. Thats not true anymore outside of JS in the browser. Raspberry Pi goes some way to aid that for scratch.
I had to wing it because the ages turned out to be younger than I expected. I've taught my 6yo son using Racket and Pyret so I had the basic approach already. Although I shot over their heads in spots, overall the girls seemed to be really engaged, as were their parents. For my money, Pyret is THE language for an intro to programming, almost regardless of age.
While this is not truly for kids since I was teaching university students I always wanted to investigate if domain specific languages should be used more.
We did some unpublished experiments for an AI class on agent development where groups developed a card playing agent in Prolog and a domain specific language for that card game. The DSL agents were quite a bit more sophisticated.
My point being...I think usually we assume kids should be taught general programming. It might be more fruitful to pick a cool domain and a language suited for that domain. Unfortunately a lot of the programming exercises/projects across all age groups are rather boring for lots of the students from anecdotal evidence. I'm envisioning something like this:
Educator: Tell me something that's cool.
Kid 1: Pokemon!
Kid 2: Football!
Educator: Ok, tomorrow we'll learn how to program (Pokemon stuff here) and (football stuff here). Educator goes home, configures the PokemonLanguage and FootballLanguage and starts teaching that language with Pokemon/Football specific examples.
Does it scale...probably not but we're in the business of doing things that done't scale, right?
Does it scale?
It's doable: there should be common libs (pre-written snippets) for moving chassis, limbs, RC over wifi, object detection[1], swarm control/collaboration etc. Educator would fit hardware/software together and rock the class.
Does anyone know of any published research on the efficacy of this "block based programming" standard the author mentions? I can't seem to find anything on the subject in the Scratch website's "Research" section (https://scratch.mit.edu/info/research/), and in their early papers they simply list it as a "core feature" rather than explaining why they use blocks in the first place.
I've been a CodeDojo and Scratch mentor for a few years and, although I haven't read much of the research, block-based programming fills a great niche for kids that know how to read, but have a hard time typing. Typing and syntax issues hinder the experience for very young children learning to code.
Scratch allows children to learn computational thinking concepts through a creative computing experience. Keeping it simple and focusing on the creative aspect of programming is a major emphasis of Mr. Resnick's team at the Lifelong Kindergarten Group.
The kids that choose to continue with programming eventually reach a wall with Scratch, where the block-based aspect breaks down. At which point they are ready for syntax-based languages. However, it's amazing how complex some of the featured projects are on the Scratch website with regards to both art and logic.
Ah that's a good point that both you and scottcha make regarding the typing strengths/weaknesses of children, which would make a typing-based approach maybe non-practical. I guess more generally what I was trying to better understand was whether or not the use of these fitted blocks (as I understand Scratch to do) has been studied enough to be considered more fruitful in developing an understanding of rudimentary programming rather than a more free-form way of doing so (maybe just blocks that can be combined in any way, even if they don't work as intended). Maybe said a slightly different way: why did MIT researchers choose to use a "coloring in the lines" method (which may hinder creativity and potentially interest)?
From my experience and interactions with the LLK group at MIT, they have been very careful to position Scratch as a creative, story-telling tool, where the connecting of blocks is just one form of expression. Making your creations come to life through art and logic and sharing with the community is at the core of the Scratch. You actually won't find the words "coding" or "programming" on the homepage (https://scratch.mit.edu/). I find that any understanding of rudimentary programming tends to be side-effect of trying to make things work :-)
In my experience in using this with my Daughter (age 7) I think the main efficacy of blocks comes from making it easier for kids who don't know how to type to use the basic programming concepts we are used to (nesting, loops, conditionals). What other aspects of efficacy are you thinking should be considered?
I mentored a CoderDojo group for Scratch, AppInventor and HTML/JS for a year (two years ago, so details are a little blurry now) and in my humble opinion the "boxes" or "blocks" are not that good. Not because the idea is bad, but because the implementation is terrible.
It's true that children have a hard time typing, but it's not because they can't type fast. The reason is that they don't know how to delete, navigate using keys, or what tab and intro are supposed to do.
The boxes are painful to manage. The only advantage is that they can use them with the mouse, that they seem to be much more familiar than with the keyboard.
Some pitfalls:
* Not obvious what kind of item should go in every placeholder.
* You need to learn in what tab page is every kind of item.
* As soon as the program is bigger than a simple proof of concept, it's difficult to read, understand or modify.
* There is some model for moving stuff around the screen that it's not very intuitive and you can't easily choose an alternative.
* The event model is probably not what a beginner should start with.
A better approach would be to use the keyboard, at least to do the same as with the mouse. Every pro knows that keyboard is way better. Don't let the cursor go out of boxes maybe. I've sit on the idea of making such an editor in JS for a year... anytime soon :-)
Oh and BTW, the children did just fine with JavaScript, once they learned keyboard basics.
Because children too young to even type their own name on a login screen can still understand and do block-based visual programming.
So, no I don't know of formal research - but that answer is the experience shared with me by teachers who are working with 5 year olds on these concepts.
I never liked anthropomorphic neotenized animals. Create a programming language with transformers or thundercats not a cat on meds (j/k, that project is cool, but you know what I mean!).
I learned to program with QBasic and I know many others learned to program with the ZX Spectrum or similar machines.
If kids can learn the abstractions of the English language, be high dans in Go, get accepted into college, and achieve incredible things, they can learn programming too.
I highly recommend the book "Surely you're joking Mr. Feynman", especially the chapter about how he fixed radios. This really reflects the magic of learning as a kid.
What I think is that education systems will evolve eventually that will be a reality for the ordinary person.
Text from educational materials can be optimized for readability, and explanations/illustrations can be enhanced to be more interactive and immersive (e.g: VR).
I learned to program with QBasic and it took me colossal effort and time to kick that crap out of my head and actually understand programming. At 31, I'm still not sure I'm completely over that.
This ignores Minecraft and things like Scriptcraft ( http://scriptcraftjs.org ) which I've found are far more effective at home my kids attention than Scratch. Scratch is nice but IMO the end result is too limited - kids sense their program is "stuck" inside the window of the Scratch environment and is missing out on much of what the computer is capable of.
Yeah I just introduced my kids to http://computercraftedu.com/ and its visual minecraft programming language. They got the hang of it quickly because they really want to create things in minecraft.
The first PC videogame I ever saw was a gorilla throwing a barrel at buildings. It was written in BASIC and came with our 286 back in 1989. I was really excited to learn how the monkey was drawn - out of the same ASCII blocks as everything else, obviously, but how? - and excitedly opened the file in a text editor.
It was a little overwhelming to my 7-year-old self to see just how many little subroutines and subprocesses were needed make the whole program work. It was a very complicated set of math processes, not unlike how a car engine is a very complicated set of physical processes. (I'd been helping with car repairs for a few years at this point, and rigged-up a pair of copper wires between the cable box and TV once when we only had 1 coax cable.)
Several years later, I was overjoyed to find the TI-82 calculators we were loaned in school could interpret the same BASIC commands, and happily started writing tiny utilities, competing with classmates for the coolest function, and joining debates about whether pre-programming the Quadratic Equation into a calculator counts as cheating on tests.
Despite setbacks like a lack of programming education in rural WA State in the early 1990s, that monkey throwing barrels planted the seed that made me want to write and understand software.
MSDOS 5 used to come with QBASIC. Nibbles and Gorillas were great games and they included all the source code.
I used to play Gorilla's all the time when I was a kid. That was how I learnt about angles. My Dad drew a picture for me "This is 90 degrees, This is 45 degrees" it used to sit beside the computer.
I learnt a lot about programming from the DOS environment come to think of it. Our home PC used to have a text based menu program it would boot into. In order to add a program to the menu you needed to edit it, using something like a markup language. My Dad used to sit over my shoulder and talk me through adding programs to the menu.
I don't think it's about being able to read text written in rows, although if you can't see that kids aren't particularly good at that initially, then you mustn't have spent much time with kids. (Hint, they learn to "read" with picture books and then books with like 5 words on a page.)
The same reason they learn to ride a bike on one with 12 inch wheels instead of 700c. Or cook using recipes with 3 ingredients.
Simplified versions for learning are a good thing.
First they grasp the basics using something simple, then they push the boundaries of that simplified version, and then they extend to the next step up.
Because they aren't very good at reading yet, because they're kids. And for some reason, kids often prioritize having fun over using the most efficient representation possible.
> Because they aren't very good at reading yet, because they're kids.
I'm not sure, but I think it may be the case that the best solution for teaching children programming at the point where "they aren't very good at reading yet" is to address that problem first. You can be a kid and be good at reading. I've known several, both when I was a kid myself and now that I'm an adult.
Exactly. I "learned" QBasic when I was 5-6 and it was really exciting because it was the actual language that implemented some of the games I liked playing. Kids like to learn about the real world. They can tell when you give them something simplified and they often don't like it.
When you're six you most likely can. And all those colorful blocks and smiling monkey-people look like something designed for one- or two-years-olds.
I was around 7 or 9 when I first saw QBasic. I definitely wasn't afraid of text at that age. The wonder of programming isn't in how it looks - it's in what it does.
Last weekend I built a project to do music with sonic pi[1] using google's visual programming blocky[2], take a look if you are interested: https://github.com/marianoguerra/sonic-blocks
I wonder why people are in such a hurry to teach their children CS/things?
{ rant: `One of my primary complaints from (engineering) school was that we/I never had the time to absorb knowledge and become intuitive with anything (the French engineering school I attended was particularly bad). We were spoon-fed knowledge. In order to sink enough time into a topic and understand the parallels with other things (at least in engineering science/craft) you need a lot of time and focus. This should (must?) not come from discipline but from curiosity. I would argue that (though I am a layman in this subject) adding another exercise to a child's schedule with soccer, birthdays, school, PlayStation, ... doesn't make them more curious. It makes them tired and unfocused just like a grown up if they have too much to do. Give them time to learn and grow instead! Give them the chance to experience mastery and to feel confident, be it playing with rocks in the yard or programming. Let them be bored. Give them time and focus. Do the things you like together so you can share of your experience. If that's is programming then fine, but do it with the tools you like or create so they can see how enthusiastic you are about something. If you like these learning tools, then go for it, but don't force it if you don't. If they are 18 years and still haven't learned to program: relax, there's is plenty of time for that! I suppose this is controversial, but in my experience the hackers that I know learnt coding really young aren't necessarily better than those who learnt it later. Those who have a genuine interest in coding are multiples of their peers.`}
I looked around the Make WOnder site for a github repo or something to download and try the language. Don't see it. How do we try this out?
I have co-taught a Scratch club 4 times for kids in the 10-12 yr old range. And will teach a Python club in the coming Fall semester for kids in the 10-14 yr old range. I am nto a real teacher but am lucky to work with a CS professor from a local college.
For the Python class I am thinking of a Raspberry Pi per kid, plus KVM. And NoStarch text as class material.
It's true it's not easy to evaluate the programming languages without a robot, but you can definitely get a feel for them by just running the apps - Wonder for state-machines (aka "flow-based programming") and Blockly for traditional Scratch-style programming.
I built an online IDE for creating HTML5 games in Javascript that is perfect for the classroom. Then I taught a class using just Javascript and HTML5 Canvas to 11 year old kids in my son's class.
They were fully capable of using straight black-and-white code to get things done. And they were thrilled to see their colorful results on the screen. Learning how to clear the background with different colors got them pumped. Drawing circles and moving them across the canvas was an actual thrill.
After only an hour, I lost control. They were off trying to make their programs do great things without me. They were trying and failing, and then succeeding, on their own. I was running around the classroom helping them figure out little syntax issues so they could keep going, and everyone was having a blast.
One kid would get his program to do something strange, and he'd call everyone over, and everyone would ask "how'd you do that!?" and he would become the teacher for a moment - and the kids would run off and keep trying new things.
There is just something magical about going from plain text to a working program. Writing "DrawCircle 10,10,50" to draw a circle is pure awesome. When you are learning - this makes you feel like a real hacker. You take this kind of thing home and blow the socks off mom and dad too.
Side-note, before I created my little web-IDE for this class, I looked at a bunch of these kid-style languages. I opted for straight code because I remembered my own beginnings. I used QBasic for everything, but when it came time to learn more advanced programming, I struggled for too long because of it. I didn't want my kids growing up like I did, not knowing what to do without GOTO. I didn't want them not knowing what to do if they couldn't drag and drop an IF block into their IDE.
I am of the opinion that kids should not be taught to program computers for these reasons..
1. Programming can be too much gratifying, almost drug like, and will keep the vulnerable kids in front of the computer whole day long, building stuff. This will help them blow the socks off mom and dad, but will make little real difference in their future.
2. learning to program early does not make really better programmers. But there are skills vital to life and experiences that SHOULD be picked and gone through, when they are still kids. This should not be sacrificed for learning coding.
So I think kids should not start programming until they are past their teens..
Source: My experience as a kid who used to blow their parents socks off by making games and 3d graphics in qbasic and turboc...
Honestly, I don't think that cute interfaces matter all that much. An ASR-33 teletype dialed into a Control Data 6600 with a Fortran compiler was a pretty damn cool thing to my ten-year-old self.
Scratch is actually pretty good at expressing state machines. Since all statements are atomic and all scripts on a sprite run in parallel, you can write one script that says
forever:
wait until Today == Saturday
repeat until Today != Saturday:
do things outside
and another script that says
forever:
wait until Today == Thursday
repeat until Today != Thursday:
if there is trash:
take out the trash
and then any process that updates `Today` will cause the sprite to perform the right behavior on the right day.
I fully agree with the sentiments here. For all intents and purposes, I think that block style languages might not be the best way to introduce programming - I'll have to say that Bret Victor's Learnable Programming makes much more sense (http://worrydream.com/LearnableProgramming/)
However, there is no (to my knowledge) better way to introduce programming in an easy 'non-keyboard' way than blocks. I ask this because I'm currently brainstorming ideas for tux4kids (an open source educational suite for kids - yes tux as in the linux mascot), and we've come to the conclusion of using block structures (since the game has to be playable for mobile too). Unfortunately, we've come no better than 'move here, use functions' a la Lightbot (lightbot.com)
It's quite timely that this has been posted here, since we're still brainstorming concepts and I wanted to take this opportunity to ask - what would you suggest for a 'programming game' for kids?
Shameless plug: I'm working on a small graphics environment to teach my 7-year-old brother programming. It doesn't have any advanced graphical GUI, instead it has a Scheme/Lisp REPL connected to OpenGL window and it lets you draw various shapes (such as triangle and squares) as well as load shapes from .obj files exported by blender. Once you load a shape, you can assign it a color or texture from PNG file, then move, scale and rotate the shape, and get basic keyboard and mouse inputs
Note that error handling in my language isn't great, and I don't have proper tail-call optimizations, but I'm working on v2 which will add more real-world features to the language.
My introduction to markup was the Geocities era HTML. I was in 3rd grade or so at the time.
Got access to my dad's Casio digital camera and took pictures of my friends and teachers and then swapped heads and bodies using Kidpix.
In computer lab, I'd set the start page on the few computers with internet to my Geocities page. It was a huge hit and the computer teacher didn't know whether to applaud or punish me for the work.
I got cut off from the 'internet computers' indefinately and played Organ trail everyday instead of doing the typing assignments since I was already proficient.
I think a large part of my comfort with code came from getting rid of the 'curly brace phobia'. I've attributed my comfort reading code regardless of language at an early age to this exposure to HTML markup.
Our app hyperPad (https://www.hyperpad.com) is being widely used to teach kids programming. It was never intended for that, but it's really interesting to see schools around the world using it to teach kids to code.
We actually built it as an easy way to make games, but hey, if people are using it to learn, we won't complain ;).
Since our app is primarily a tool to make games and other interactive apps, we take a different approach to our behaviour system. The hyperPad behaviour system is our take on a node based event driven programming language that lets users focus on the design and the fun parts. But still give them the power they need :).
I loved this game as a kid and, while it's not really a programming language of sorts, it's great for getting you to think in a programmer's mindset. Logo bored the crap out of me, but I could make neat things with it. I feel like it was completely forgotten but something like it could have a real educational use today.
I think a good intro to programming is video games, especially ones that let you build custom maps (for me it was Age of Empires and Starcraft). All the units and such can be seen as a huge metaphor for object-oriented programming. With some games you can also add in custom scripts. Of course this doesn't teach practical skill, but at least can get them thinking of the concepts while engaging them with something more exciting than hello world or a calculator.
