I try to remember what it was like when I was a young child learning to program, and if there is one thing that I remember, it was that I did it for games. I was lucky enough to be 6 years old in 1980, when you could get BASIC game listings in computer magazines - you'd type them in and hey! new game!
But before even starting to type in those games, my father had shown me a few simple things that you could do in BASIC, with prints and inputs and some simple loops/gotos/gosubs. That meant that I could understand the language that I was typing in from the magazines.
More importantly still, I was using a somewhat orphan computer called a Compucolor II. It didn't have the same graphics calls as those found in the magazines for TRS 80/Apple ][ etc. So I had to learn to translate the graphics calls to something that made sense for my computer - in general it was only a small part of the program, so not too daunting, but it meant that I actually had to think about what I was doing, not just typing code into the computer.
I played a bit with Logo at around the same time (my father was a CompSci teacher), but it never engaged me the same way that those first BASIC games did.
The other big influence that I remember from early childhood was a book that contained a full text adventure called Haunted House (or something like that). The book had lot of pretty pictures, but more importantly it explained how each bit of code actually worked, how to store room descriptions, state flags, objects in the inventory, how to write a simple parser etc.
Better yet, towards the end of the book, there were challenges - how could I modify the game so that the player has to retrieve a key that was hidden in the drawer of the desk in room 16? How can I modify the game so that the player is eaten by a monster if they spend too many consecutive turns in room 27? And how can I give warning of the monster's approach so that they know to leave? By the time I'd finished that book, I had a pretty good understanding of what programming was about.
In the end, I think that all of the discussion about what langauge to use is pointless. For what it's worth, I think that the keys are the ability to create simple arcade games with less than 100 lines of code, plus some sort of book/aide that a kid can go through at their own pace that explains how to write a more complex game. Data strutures? Object oriented code? functional programming? No, these are abstractions that are quite simply too hard for most kids to grasp. I think arrays are about the limit that young children can understand effectively. Get them started on thinking about how to break down problems into simple parts that can be solved. Get them actually coding by choosing a subject matter that interests them. The rest will come later quite naturally.
I would say that C, an arduino, a bunch of resistors, LEDs, a VU-meter then hack something fun out of that. Nothing could beat the feeling of programming something you can wire and hold in your hand. Especially for children.
But before even starting to type in those games, my father had shown me a few simple things that you could do in BASIC, with prints and inputs and some simple loops/gotos/gosubs. That meant that I could understand the language that I was typing in from the magazines.
More importantly still, I was using a somewhat orphan computer called a Compucolor II. It didn't have the same graphics calls as those found in the magazines for TRS 80/Apple ][ etc. So I had to learn to translate the graphics calls to something that made sense for my computer - in general it was only a small part of the program, so not too daunting, but it meant that I actually had to think about what I was doing, not just typing code into the computer.
I played a bit with Logo at around the same time (my father was a CompSci teacher), but it never engaged me the same way that those first BASIC games did.
The other big influence that I remember from early childhood was a book that contained a full text adventure called Haunted House (or something like that). The book had lot of pretty pictures, but more importantly it explained how each bit of code actually worked, how to store room descriptions, state flags, objects in the inventory, how to write a simple parser etc.
Better yet, towards the end of the book, there were challenges - how could I modify the game so that the player has to retrieve a key that was hidden in the drawer of the desk in room 16? How can I modify the game so that the player is eaten by a monster if they spend too many consecutive turns in room 27? And how can I give warning of the monster's approach so that they know to leave? By the time I'd finished that book, I had a pretty good understanding of what programming was about.
In the end, I think that all of the discussion about what langauge to use is pointless. For what it's worth, I think that the keys are the ability to create simple arcade games with less than 100 lines of code, plus some sort of book/aide that a kid can go through at their own pace that explains how to write a more complex game. Data strutures? Object oriented code? functional programming? No, these are abstractions that are quite simply too hard for most kids to grasp. I think arrays are about the limit that young children can understand effectively. Get them started on thinking about how to break down problems into simple parts that can be solved. Get them actually coding by choosing a subject matter that interests them. The rest will come later quite naturally.