I did something similar for my kids class (mix between 3 to 5 year olds).
The first thing I did was make a game in Unity (very simple, no death just collect things) that featured their faces and school uniform (had written permission from all parents). The kids were amazed at it and asked a lot of questions. The main point I tried to explain was computers are also for 'working' and 'creating' games, not just playing them and you could make games by 'programming' and explaining a bit what that is.
After this, I tried to explain what an algorithm is. Sounds strange to try to explain this to such young kids, but you can relate to real world situations (in this case, they have a 'routine' for lunch that never deviates, so I related to this and other routines) but to make it interesting, at the end we played a little game where we drew a grid on the floor, and we had to program a 'robot' to go forward or turn to get from one place to another. The robot was usually one of the kids and the others had to give instructions. We started to have one instruction, do movement, one instruction, do movement to having them try at least to do 4-5 instructions to get to the end. The kids loved the game and the teacher even created a small table based one for them to play by themselves.
After I took a Sphero ball, did a small app to control it based on the game we played before, and let the kids try to do the same, but this time controlling an actual 'robot'.
While I didn't show them any code, they understood that they could create 'routines' in the computer to control or display things. Was pretty cool (and the parents loved it as well when they saw the game and the kids explained to them what an 'algorithm' is :))
(this was over the course of a few weeks, so it wasn't a full day of them trying to learn everything)
Part of Seymour Papert's pedagogical idea of programming the turtle seems to me to be that the the students can put themselves mentally in the position of the turtle and ask "how would I know what to do next?", ideally with the insight that we're looking for a rule that can be expressed in language and that answers the question in every situation. That sounds very akin to your lesson!
I guess the Sphero ball might be a kind of update of this.
Your method sounds a lot like lightbot[0], which I've had a lot of success using with 10-12 year olds. Check out their flash demo, it's actually kinda fun for a few minutes.
EDIT: just noticed lightbot jr. That wasn't there when I used lightbot, but if it's at the same standards as normal lightbot I'm interested.
In Portugal. Called Escola Moderna (Modern School). not sure if this is a more national methodology or international.
The main idea of the kids learning is through experimenting with things. They are also VERY keen on parents going there and spend the day with the entire class talking about their jobs, or just general things (some parents did gymnastics, other baked cakes, my ex-wife did a hands-on demonstration of what a paramedic may do on an accident. I mostly focused on science stuff, built paddle boats with them with rubber bands to teach them about physics, made the games mentioned before, etc)
If this isn't available, try Montessori schools as they share a lot of the ideas with Modern School.
Well, we programmers are WRITERS who have to think thoroughly and write very carefully, because our READERS always take our words literally, and we really don't want things to go bad.
After being downvoted, I'm trying to understand what could have hurt someone sensibility. Maybe the word _writer_ feels far from the shiny tech scene, but in the end we ARE writers, and of the highest qualities. Kids understand what a writer does, your parents too. So I think that it is a good approach to explaining what a computer programmer does, in the end.
A guideline to keep in mind (from https://news.ycombinator.com/newsguidelines.html): "Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized."
Also: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." Though I'm personally fine with legitimate questions about expected behavior.
Your explanation makes sense to me. My son is 5 and loves Lego. I just tried explaining that someone had to write the instructions in the book, that my son has to follow to build the final piece.
The programmer is the instruction writer, the computer is the lego builder.
Like any analogy, it isn't perfect, but for a 5 year old, that was enough to satisfy him for now.
This court can find no meaningful difference between computer language, particularly high-level languages as defined above, and German or French... Like music and mathematical equations, computer language is just that, language, and it communicates information either to a computer or to those who can read it.
My fiance recently tried to explain in a foreign language to a lady of advanced age which she is taking care of what is it that I do. The term writer was the closest thing that made any sense to that lady.
It has(Italian), but how do you explain this concept to someone who was born before Turing's groundbreaking paper was published and worked most of her life for a newspaper?
I've been priming my nieces on how computers operate by playing a simple game with them. I pretend to be a robot and they give me instructions. When they say 'turn left' I keep rotating until they tell me to stop or do something else. When they say 'sit down' I just sit wherever I am, even if there's a chair right behind me.
They think I'm just being silly and we all have a laugh but they're getting the hang of it!
A teacher I had in ≈ fourth grade did this with our class. We had to make a PB&J sandwich. It was entertaining, and like your example, he pushed us to give the same amount of precision in our answers, all while having some fun.
We did this too, but I have no idea why, because we weren't learning programming. It's probably the only thing I specifically remember about 6th grade. Maybe it was to teach us to be just as precise in our homework or something.
"Be precise." It's something we take for granted as engineers. A lot of people don't understand the importance of exact instructions and algorithms, expecting the other party to intuit the desired meaning of a command. I think this is a clever way to teach kids early on.
Yes, that is exactly what the many teachers who are teaching coding to young kids in schools are doing. First, you get them to understand the idea of a series of instructions by doing it in real life. You can cover quite a bit of the fundamentals of programming without even talking about computers. Algorithms, logic, sequences, loops... these are all explainable by having kids direct each other around a room.
Once they understand the concepts, THEN show them how to make them happen on a computer.
Wow I've been doing EXACTLY the same game with my daughters! They have to tell me to go and stop and turn and stop, and if they don't say stop I walk into a wall and they laugh and laugh. Lots of fun.
Recently, at the age of seven, my son discovered how the remote control works. He was proud that he figured it all by himself.
And I was proud that my son discovered that at the age of seven and not at the age of two or three.
When my children wakes up in the morning they don't switch the tv on or any other screen.
They play.
They build stuff with Lego or wood game. They draw. They go in the garden to play with the dog or with their bikes.
Of course they sometimes play a game on my tablet or telephone, it's not 20th century anymore.
But they don't own any. And they don't choose when they can watch a screen. (Steve Jobs did the same with his children after all [0])
Despite that, I will start to teach them programming next school year, I've bought a PI for each, and I welcome the article ! It's just I think this is important, but not a priority for youngs.
I'd imagine there's a lot of vegan households that forbid the consumption of milk and other "harmless" foods in California, so it doesn't seem strange at all.
> When my children wakes up in the morning they don't switch the tv on or any other screen. They play.
It seems like you may be conflating the medium with the activity, and that you're not a fan of exposing kids to computing devices until relatively late. Which is fine, of course! Good parenting comes in many forms.
That said, I don't feel bad that my son prefers playing/building in Minecraft to Lego (although he does that too) and started relatively early. For us, any activity that isn't passive media consumption is a win.
As long as you are providing ample opportunity to develop a range of fine-motor skills, and 3-D visual perception at many ranges of distance, and interactive spoken communication, and not fixing gaze at a single distance for extended periods of time.
As stated my kids are only 7 yo and don't have their own devices yet, so I haven't got any experience in monitoring their screen time other than be careful about it on a daily basis.
But I guess when they grow up and have the opportunity to access it, say, in their bedroom, something like that might actually be useful.
Reading through this link, I like that the author/presenter is trying to relate things to what the kids experience. That said, it still felt a bit all over the place. That's OK, of course, as I wouldn't expect much more than to pique the interest of the children, inviting them to explore a bit on their own later.
It's a pretty good basic introduction, in my opinion. It doesn't get too complicated, either, presenting different types of computers, the basics of binary numbers, input and output, and also has online resources available as supplement. If you can find a copy at your local library (which is where we picked it up), give it a look-see.
> the author/presenter is trying to relate things to what the kids experience. That said, it still felt a bit all over the place.
Arguably, a kids experience is all over the place too ;). But I guess that's one of the tasks in education, and what you're getting at: teaching them to stay concentrated.
To add a thought: I'm coming around to, in non-group situations, trying to accommodate distraction rather than steamroller over it.
I teach clay pot throwing. Younger kids particularly are often highly distracted. In part that's because of the tactile nature of the medium. I'm finding that if I go along with the distraction, playing with how the water feels say, then we can usually get the central activity (making a pot) done "better".
For me it's key to recognise that distractions are often moments when something is inspiring the child, aside from the central task, and that the child is learning still in such situations (just learning about other things than are included in the 'lesson plan').
That sounds like a great approach for that type of hands-on teaching!
I was teaching at a uni for a year - bachelors, masters, so all young adults. However, especially the bachelors were still in the process "unlearning" the high school attitude, that is: learning what you have to in order to pass, not because you want to understand the subject.
When teaching theory, the most effective way to shift them to the second mode of thinking and keep them engaged, was chopping up the lectures into ten to fifteen minute chapters, with two to five minutes of mini-discussion breaks. These would include an optional topic starter, "now discuss how you would apply what I just explained to X", where X is something that at hopefully least one in the group can directly relate to from their own lives.
I think replacing long lectures of passive listening with that type of short loop - passive listening/active discussion doing - would also work for younger ages. I don't believe long lectures are good in general, even if you're into the material. They make you wait until you can actively engage with what you've learned and force you to keep it all in your head until then. Just adding short breaks of talking about it with the person next to you already helps a lot.
I was once got a chance to describe to a class of kids in Marin County what programming is. They were maybe 10 years old. I used the analogy of a robot that does exactly what you tell it to do. A little girl raised her hand as asked, "Like my maid?"
I've build with them a robot mask from a cardboard box. (fun!)
Put on the mask and told them that the robot is stupid, just understands 2 commands: step forward and turn right.
Put them to teach the robot to go around the room. Asked how to make the robot turn left. Created a command to turn left. Abstraction! Simplified some commands with loops.
Agreed 1000%, the article just seem to overcomplicate things, why talk about processors, discs, binary? This is ridiculous!
All children can relate to physical movement and giving commands, lets start there! It's like we're throwing all the knowledge we got from Logo over board (2017 is Logo's 50th birthday!)
I've done this before, this is the perfect way to illustrate EVERYTHING about programming, even engineering. Explaining sensors, input/output (keyboard), how it has no way to sense how or whether or not it's even moved forward. The robot just does.
Why don't we focus on teaching critical thinking and making kids comfortable with abstract concepts? Do we need to call it programming and overwhelm those around us. These are skills that translate to most of life's situations and decision making. when I started programming my biggest obstacle was the fear of seeing error codes.
I believe that just like any other topic in life such as math, science, music, etc.
There's no easy way to explain programming to the majority of kids that doesn't involve oversimplifying it.
There's simply: the group of kids who are curious about it, who want to learn about it, who are willing to go through the rigor to learn it and then there's the other kids who don't.
If a kid isn't interested then there's no amount of simplifying it that will make them get it.
Formal operations typically develop at around age 11 (cf. Piaget); this mental capability is necessary to (among many other things) comprehend abstraction, isomorphism, algebra, recursion, and most of the other mathematics-originated components of computer science. How can children without these capabilities, possibly comprehend programming, to any extent beyond the trivially concrete?
It means you need to keep the learning tangible, tactile, and concrete. Simple robots are great for that. At that age with my kid, we did Logo+Turtle graphics, with a "be the robot" walk-through before coding. Also we got a Pro-Bot from Terrapin Logo, which is again create concrete, observable output from simple programming steps. Somewhere along the line we had a robot that I don't think is made any more, but it had a paper disk with two channels of information for driving the two wheel motors, and you programmed it with a black crayon.
The key is keeping a direct, concrete connection between program and output. Multiple steps of abstract thinking don't work well.
> Somewhere along the line we had a robot that I don't think is made any more, but it had a paper disk with two channels of information for driving the two wheel motors, and you programmed it with a black crayon.
Sounds like one of the old OWI MOVIT robots - they used to sell a version (I think it is discontinued but still available from some vendors) called the "Binary Player Robot Kit". It doesn't look the same as the original version in the 1980s, but the internal circuitry is probably identical.
I've noticed this with my kids. You can try to teach something, put a lot of effort into it, make slow and unreliable progress, then back off and then a year later they try again and pick it up instantly because their brain is ready. The key is to provide the opportunity at intervals, and don't push if they aren't ready yet.
Without abstraction/generalization capability, how are they able to learn the entirety of the concept rather than merely analyze your concrete examples?
Algebra can be taught to young children by making it concrete. Call the variable boxes, and give them actual boxes to represent them. Color code the units, and don't allow them to mix colors. Tell them to play fair: "You may only give something to the right side, if you also give the same thing to the left side. Same goes for taking things away, or splitting into shares, or asking the teacher for a copies of one of those boxes. Yes, you can do that, just share it fairly between the two sides of the play area." Kids get the rules of fairness really quickly, and those rules map closely to the basics of algebra.
I was part of a study where this was attempted, at about age 8 or 9. IIRC, it worked well for about half of us. The teacher totally blew my mind when she took all of my boxes and tokens, put them in her larger pencil container, and told me that my game was now just a piece in a bigger game.
With current US primary+secondary curricula, most non-remedial students still only get as far as differential calculus before graduating high school - electronics and discrete math are already missing from that, and "concrete programming demonstrations" would strain the schedule even more.
I feel like at 6 years old you understand enough to describe state machines.
I did this when I was 6 with the older lego RCX brick. I didn't understand the limitations of the graphical programming language at the time because nothing I thought of was complex enough to push them. It still probably helped me understand intuitively how "dumb" computers are which can be pretty hard for beginner programmers to grasp for some reason.
> It still probably helped me understand intuitively how "dumb" computers are which can be pretty hard for beginner programmers to grasp for some reason
Grasping the dumbness of computers can also be done via a bottom-up approach: transistors, then gates, then boolean-logic/state-machines, then binary-numbers/ALUs, then processors, and so on. "You think it can do X? Then show me how that could be built, using what you've learned so far!"
(Analogous, of course, is learning mathematics starting with a 3-column-proof-based approach, rather than ... err, whatever they call the typical American approach.)
Just off the top of my head, there's the 5-year gap between age 6 and age 11, during which this journey does not progress and the memories from age 6 can degrade.
Well, there are plenty of example of kids who do learn programming at that age, so I guess your ideas must be incorrect.
Personally, my parents got me a Commodore 64 when I was 6, it happened to come with a copy of 'An Introduction to Basic Part 1', and I successfully worked through it.
I once explained a kid how to create a web page in plain HTML and some simple JavaScript, and that seemed to have completely removed the shroud of mystery from what programming is all about.
Of course there is much more to programming than writing HTML, but setting the entry bar low enough can help tremendously getting one interested in learning it.
I think this is the first time in my children's lifetimes (roughly five years for the oldest) that I've considered the fact that their understanding of where movies are kept is different from most people due to our goals of going mostly streaming when it comes to media.
When I was about 6 or 7 there was a complete section of my math textbook which contained informations and example on the BASIC language. We, of course, never read those chapters in class but I did anyways while bored with the actual stuff the teacher would say.
It would use a very simple and systematic flowchart representation to model control flow. The great thing about it is that once you understood < > = (also taught in the class) the whole program could be readable.
I think I was the only one to read it and pretty much got the feeling it wasn't important as nobody, even the teacher, payed any attention to it.
I remember thinking that math classes would be far more interesting if we were allowed to hand in a program to solve the class of problems they were asking us to manually and repeatedly solve, and to bring that program to the exam. Presto: actual comprehension of a nontrivial problem space, real world documentation skills and no rote learning requirements.
> I remember thinking that math classes would be far more interesting if we were allowed to hand in a program to solve the class of problems they were asking us to manually and repeatedly solve, and to bring that program to the exam
With programmable graphing calculator that's sorta possible. At least, I've done it a few times.
Alas, it was most often banned from exams because "I can't see what you have done there to get that answer".
Also, most of the class ended up using my program for a specific class of problems we had to do in maths. In retrospect, I probably caused some harm by getting my classmates to be that lazy during exams.
> I remember thinking that math classes would be far more interesting if we were allowed to hand in a program to solve the class of problems they were asking us to manually and repeatedly solve, and to bring that program to the exam.
How do you have test cases without first solving a number of problems in the space without the program you are writing?
I once knew a 2nd grade kid who was learning calculus and competing in AIME. An incredible outlier? Or is it possible for children to develop these skills through practice and early training? I wonder how many of our attitudes and beliefs towards early education are dictated by tradition (what we went through in our childhoods), vs. what is actually possible.
Think of the potential when someone learns to program at 6 years old, and keeps at it! I hate to use the word "disruption" but I really wonder if education could potentially be "disrupted."
It depends on what you mean by "learning" calculus.
Of course it's an incredible outlier.
Even for designated geniuses, the ones who excelled all life and ahd strong parental support and become world-famous mathematical achievers, calculus at age 8 is unusual.
There's plenty of room to increase the level of achievement across many inherent-skill-level bands, though, with focused training.
It is, but it shouldn't be. I taught my niece calculus, programming, foreign languages (mostly swear words, her mom got mad!) She was like a sponge and just soaked it all up, I made it fun and she loved it.
I think all kids have that potential but the education system lets them down, class sizes are too big and can only go as far as the curriculum or slowest kid there.
Yeah I didn't word it too well. I was just trying to say that this example made me question if the ceiling for normal 2nd graders is really basic multiplication and division, as is taught in public school curricula. I'm leaning towards no. Of course not all kids will be able to reach this level. But surely they can go beyond the current level.
My wife's school has cubetto [0]. A toy to get the kids familiar with programming. Recently, in last kickstarter I bought my own because I love the idea. In addition, on my kids school they ask for parents with experience software engineering to give courses outside the regular hours. When I gave it once at my own work during an open day I used a fun game similar to cubetto (but digital). Kids love to be busy, so making it physical next time as suggested here is something I will definitely try out next time.
A couple of years ago, we tried literally giving some five to seven year-olds a computer science lecture (because we also wanted them to be able to play at being uni students, sitting in the big lecture theatre)
Used a deliberately home made looking game that looked like Angry Birds (using a child's sketches of the birds) and exposed a few lines of code that the children could tell me how to edit. Worked really well, but it's partly like thinking about putting on a small stage show
A long time ago, I taught community college course on programming for children. Here's my approach.
Very young children aren't ready for abstract concepts as the first introduction. We need to progress very slowly and relate to the familiar.
1st: we talk about a recipe for no-bake cookies.
I bring the ingredients. I show them the "program" (recipe), and the kids play the part of computer -- following the instructions.
Then we take a look at the LOGO language. The move commands issues to the "turtle" demonstrate visually the commands being given. Again, very high level, very concrete.
Next, we talk about a variable. I pick some kids and they each "hold" a number written in marker on a large sheet of paper for everyone to see. The variable name is their name (Joe, Sue, etc.). They know they can only hold one value at a time. So if I give them a new number they throw the old one away.
Then we step into Basic and learn to print a simple message.
Eventually we combine the two and end up with something like the old favorite:
10 for i = 1 to 10
20 print tab(i)
30 print "joe"
40 next
which, if you've not seen it looks a little like
joe
joe
joe
joe ...
From there, I let the kids' interest guide me. We might talk about how a "Guess a number" game works, or even graphics and "Snake Byte" (Chuck Sommerville -- early 80s).
Meh... I prefer his approach. Teaching Scratch to a bunch of kids for half an hour would just have ended in them thinking "that's cool... but what is it for?". They would still have no idea how programming relates to the real world and their experiences.
His way of teaching instantly draws a connection between the work of a programmer with the world that the kids live in, which is terrific value for a child. Sure, they're not walking away with any technical knowledge, but that wasn't the point of the presentation.
But his approach is boorrinnggg. It's just like any other school lesson.
Throw some wheels and a motor on a board and create a simple abstract language:
drive()
stop()
turn()
wait()
Boom, now you have them programming and have a freaking robot moving around!
I don't think we should be starting out with even mentioning binary to college students in the intro class, let alone 6 year olds. How are either of them going to use that knowledge? The college kids will use it when they get to their assembler class...otherwise that's about it.
Messing around with a super abstracted language will give them the only thing they should get out of the lesson: you tell a computer what to do and it does it.
I thought that binary was interesting as a 6 year old kid... and other number systems. And codes and ciphers. And mythology. In fact, if there was a different way of encoding information, I was intrigued by it.
This doesn't mean everybody would be -- and I think your approach of having a board moving a robot car is a great idea that probably has a broader appeal -- but it's probably good not to rule out the idea that there could be even a natural curiosity about binary numbers.
> Messing around with a super abstracted language will give [the 6 year olds] the only thing they should get out of the lesson: you tell a computer what to do and it does it.
What is the point of that lesson at that age, then? As far as I can tell, it will be of no consequence to them until high school.
> I don't think we should be starting out with even mentioning binary to college students in the intro class ... How are [the college students] going to use that knowledge?
Ideally, CS would be taught in a "bottom-up" fashion, from transistors to gates to adders to processors to higher- and higher-abstracted concepts; with Haskell etc occurring last, or nearly so. Then we'd actually have a much more solid grasp of what's going on "under the hood" and can make more informed decisions (e.g. for iterating quickly through many structs, better to actually have 1 struct of arrays/B-trees than 1 array/B-tree of the many structs; both of which are better than anything that involves a linked list; all due to how processor caches work).
In such a situation, binary would indeed be important for assembly and arithmetic units; but also for e.g. knowing to replace expensive integer divisions with cheaper right-shifts when possible by making the divisor be a power-of-2.
I make this same argument for today's Code Schools. They teach high-level language/frameworks like Ruby on Rails, and the graduates can do productive work, but often have no idea what's happening underneath. Take serialization for instance -- with a limited understanding, the DOM just somehow magically stores data and retrieves it later; but the operator has no understanding of a database, or knowledge of SQL, or a sense of the value of referential integrity, or foreign key indexes, or how to use explain plan to see where the time is going, etc. So when it comes time to tune/refactor/redesign for performance, the student is lost and goes off looking for some Gem to drop in and solve the problem.
Perhaps it's just a natural stratification of the industry, but it leaves me feeling uncomfortable and frustrated when a jr engineer doesn't understand what's happening underneath the veneer of Rails (not to pick on Rails solely, this could also apply with many other frameworks & languages - I just see this the most because it's the latest fad) and/or doesn't understand why reentrancy, interrupts, or parallelism with mutable items is dangerous and hard-as-hell to get right.
I would love to see more developers with at least a passing familiarity with the basic concepts of computing, of the sort presented in Chuck Petzold's book CODE (which I highly recommend).
[just read my post - I really am sounding like a grumpy old man these days, but I'm clicking "reply" anyway. Stay off my lawn. ;)]
(Of course, being an undergraduate CS student, from my point of view the idea is better expressed as, "I would love to see more companies who value internship candidates with more familiarity with the basic concepts of computing, of the sort ... ".)
I first exposed my kids to binary, and other number bases, when they started learning the decimal place system (4 or 5 years). It seemed to fit really well there.
When they do/did multiplying by 10, and doubles, it's a good time for a review (why does a decimal shift produce a x10, etc.).
You can use that to talk about codes (crypto), communication (Morse, etc.), computation using "switches", logic. It's a good base for a lot of interesting stuff IMO.
I remember my first encounter with "programming": It was a Turbo Z 32.8 SL programmable toy car. I was fascinated by the fact, that I could input a set of instructions and the toy would store them in its memory and execute on command. Naturally I was also disappointed with the lack of sensors or the ability to add control structures, but it was enough to spark my curiosity.
Also toy train sets with rail switches and loops are a perfect, tangible example of how a program executes.
Has anyone worked out a way to turn the Minecraft player into a Logo-like turtle? That is, drive all interactions (walk a step, jump, extended jump , hit, use, hear zombie moan from the sound effects subtitling, etc.) from within Python? The Raspberry Jam mod comes close, but actual movement of the player is not in the API.
There are a ton of children who would get right into such an updated Logo turtle.
This is really not a good way. Kids are naturally interested in tools that are magical. You need to show that power right away and without having to lecture them for an hour. Here's how I would do it. Go to some online interpreter for BASIC[1]. Type
10 PRINT "Hello World"
Tell kids that you can make computer print any message. After some fun suggestions, put next line,
20 GOTO 10
Kids would immediately get it what just happened. Then introduce, how to print message just 5 times,
5 FOR i = 1 to 5
Then ask them to sum numbers from 1 to 5 verbally. As they do it, ask them to sum numbers from 1 to 100 and watch the frowns. Now ask them what they would want in return if teacher really told them to do it and how long it would take them. As they reply, write 5 lines of code that does that.
10 SUM = 0
20 FOR i = 1 to 100
30 SUM = SUM + i
40 NEXT
50 PRINT SUM
At this point kids with programming aptitude should be hooked. Rest would be still puzzled a bit. To get them onboard, switch to graphics mode and start writing code for fun stuff like expanding circles. Making series of beeps. Doing piano tunes. Gradually move towards more visual stuff like basic fractals, equation plotting, random color noise. Generate sound waveforms and play it. Before you run code ask them how things would look and then run. Start adding interactivity. If you are doing great, there would be suggestion to make a game. Go for it! Watch wishlist keep flowing and hours pass by.
Note that I have purposely chose BASIC language above. It's fairly forgiving with syntax. It gives error messages which are much more digestible.There is no overhead of includes and imports that very often trips off new comers in mystery land. All you really need is kids to understand just two constructs GOTO and IF-THEN. Its extremely easy to understand these two and they would be able to grow from there.
PS: before anybody cries about GOTO considered harmful and suggest everyone needs to start with functional programming, I'd suggest try that idea first on real group of kids. There are always 1 or 2 kids who would be lucky enough to survive through and "get it" but you will turn rest of them against programming very quickly.
If you find this kind of stuff interesting/challenging, you might want to read some stuff from Seymour Papert who dedicated large portion of his life to figuring exactly this: how to teach kids to program. His definition of "programming" was a bit broader, though.
Children need to learn how to use the 21st century, or there's a good chance they will lose the 21st century. - Alan Kay (2016)
Television is the last technology we should be allowed to invent without a Surgeon General's warning on it. - Alan Kay
With a good programming language and interface, one - even children - can create from scratch important simulations of complex non-linear systems that can help one's thinking about them. - Alan Kay (2016)
Most of my ideas come in "waking dreams" (this is a state that most children indulge in readily, but it can be retained in a more or less useful way - I don't think you quite get into adulthood by retaining it, so it's a tradeoff). Main thing about ideas is that, however they come, most of them are mediocre down to bad - so steps have to be taken to deal with this major problem. - Alan Kay (2016)
The best analogy I've found to explain programming are cooking recipes.
You have input (ingredients), a procedure (recipe), output (what the recipe is for). From there you can start a transitioning towards more abstract ideas.
An exercise that stuck with me from when I was in 4th grade or so was when everybody in the class had to write down instructions on how to make a peanut butter and jelly sandwich, and then the teacher would follow the instructions very literally and see how close everybody could get to a sandwich.
Of a class of like fifteen kids, I believe I was one of the only kids to end up with something that was recognizably a sandwich (slice of bread with jelly on a crumb face, slice of bread with peanut butter on crumb face, slices put together such that the edges of the two slices line up and the peanut butter and jelly are on the inside as opposed to the outside).
And it's not mere coincidence that one of the first programmable machines was a loom that took paper-tape instructions, in the year 1725. https://en.wikipedia.org/wiki/Basile_Bouchon
Right. And Herman Hollerith (of IBM fame) took punched cards, that were mainstream in the textile industry, and used it to create the "tabulating machine", the computer used to streamline the US census.
we play robot turtles. we only use function frog as a jump at this stage but it's fun to see her describe mistakes in her drawings and other games as 'bugs'. we messing around with scratch jr as well but only when she wants to. odd squad is what it's all about at the moment ;-)
The first thing I did was make a game in Unity (very simple, no death just collect things) that featured their faces and school uniform (had written permission from all parents). The kids were amazed at it and asked a lot of questions. The main point I tried to explain was computers are also for 'working' and 'creating' games, not just playing them and you could make games by 'programming' and explaining a bit what that is.
After this, I tried to explain what an algorithm is. Sounds strange to try to explain this to such young kids, but you can relate to real world situations (in this case, they have a 'routine' for lunch that never deviates, so I related to this and other routines) but to make it interesting, at the end we played a little game where we drew a grid on the floor, and we had to program a 'robot' to go forward or turn to get from one place to another. The robot was usually one of the kids and the others had to give instructions. We started to have one instruction, do movement, one instruction, do movement to having them try at least to do 4-5 instructions to get to the end. The kids loved the game and the teacher even created a small table based one for them to play by themselves.
After I took a Sphero ball, did a small app to control it based on the game we played before, and let the kids try to do the same, but this time controlling an actual 'robot'.
While I didn't show them any code, they understood that they could create 'routines' in the computer to control or display things. Was pretty cool (and the parents loved it as well when they saw the game and the kids explained to them what an 'algorithm' is :))
(this was over the course of a few weeks, so it wasn't a full day of them trying to learn everything)