I taught 3 Bootstrap courses last year to middle-schoolers, with pretty good success. Bootstrap is an introduction to functional programming in Scheme. The students write simple callback functions to implement animation and collision detection in a 2D side-scroller video game framework.
I think it's a pretty good introduction to programming for kids of middle school age, though it assumes familiarity with elementary algebra and the Cartesian coordinate system. Others have taught it to students in the 5th grade, who had no prior algebra experience, though I can't personally vouch for how effective it is for those students.
I modified the standard Bootstrap curriculum quite a bit as I went along, removing the written workbook exercises completely (my students hated them), and replacing them with interactive programming exercises. I replaced some of the least-engaging programming exercises with some of my own creation. For example, I designed a lolcat image macro exercise for the "Introduction to images and strings" lesson. It was a huge hit: kids were making screenshots of their images and sending them to friends. I also added support for projectiles, background music, and user-defined sounds to the standard 2D game engine, in order to make the final games more compelling.
In the future, I think I'd rather use a problem- or project-based approach to teaching introductory programming, but Bootstrap is the best freely available, structured curriculum I've found so far. My main frustrations with it were the written workbooks, which I eventually dropped, as mentioned above; and the fact that I only had 10 90-minute sessions, meeting once per week, to teach it. That's barely enough class time to get through all the material, even if things go perfectly smoothly. It's definitely not enough time to give students the opportunity to explore and experiment on their own, nor especially to fail and then learn from those failures, which, in my experience, is the most effective way to grok programming. However, the compressed timeline was a limitation of the after-school program I was teaching in, not Bootstrap per se.
Find out more about Bootstrap here: http://www.bootstrapworld.org/ I'm happy to give you my modified Bootstrap framework (with projectiles, etc.) and the Keynote slides I used for my lectures. The slides have very few words; they're mostly animations, diagrams, and images intended to reinforce the oral lecture.
I also "taught" a couple of Scratch sessions to middle-schoolers. You don't really teach Scratch, though; in my case, it was more like giving a 10-minute demonstration of building a simple Scratch program, and then turning the students loose, and giving them a bit of assistance when they got stuck.
Student engagement with Scratch is typically much higher than with Bootstrap, in my opinion. My Scratch sessions were each about 2.5 hrs long, and almost all of the students kept experimenting from start until finish, with 3 or 4 even staying an extra hour afterward during their free period. However, personally, I think I'd move on pretty quickly from Scratch to something capable of procedural abstraction, if a student showed a continued interest in programming after a month or two of Scratching. Among other issues, there's simply no means for students to create their own blocks in Scratch, nor to encapsulate groups of blocks into larger blocks. However, I just heard from a friend that there's a new version of Scratch coming, code-named Sage, I think, that will provide at least some of this missing functionality.
Scratch certainly requires less effort on the instructor's part than Bootstrap. Scratch includes a ton of assets, for one thing. With Bootstrap, when your student(s) come up with a game idea, you might have to help them find images, and then do some Photoshop work to extract them from their backgrounds, scale them, etc.
Another problem with Bootstrap is that the students seem to be quite confused about control flow. They don't understand how the whole process starts, proceeds, and then repeats itself. The confusion occurs because the students are only writing callbacks, and are never exposed to the event loop of the game engine.
Scratch does not have this problem. Scratch programmers are entirely responsible for deciding how events are sequenced (when they need to be, at least; without explicit sequencing, everything in Scratch executes in parallel by default, which is how the real world works and is therefore familiar).
I think understanding control and/or data flow is a crucial concept for introductory programming. It helps the student develop a complete mental model for how programs, when executed, create dynamic processes. For my Bootstrap classes, I came up with a pretty silly real-world scenario in an attempt to explain to them what Scheme and the game framework were doing behind the scenes, to give the students at least some sense of "who" or what was causing their functions to execute, but I'm not convinced they really understood it. There was a bit too much magic going on for my liking.
This reminds me of when I was 10 years old and got a copy of Think Pascal for the Macintosh. Previously I had done the usual AppleSoft BASIC, Logo, and even some Assembler and HyperTalk. But GUI programming stopped me short—partly due to the unattainable cost of InsideMacintosh—but mostly because the basic control flow was an inscrutable mystery to me, with nary a mention in any documentation I could find.
I think it's a pretty good introduction to programming for kids of middle school age, though it assumes familiarity with elementary algebra and the Cartesian coordinate system. Others have taught it to students in the 5th grade, who had no prior algebra experience, though I can't personally vouch for how effective it is for those students.
I modified the standard Bootstrap curriculum quite a bit as I went along, removing the written workbook exercises completely (my students hated them), and replacing them with interactive programming exercises. I replaced some of the least-engaging programming exercises with some of my own creation. For example, I designed a lolcat image macro exercise for the "Introduction to images and strings" lesson. It was a huge hit: kids were making screenshots of their images and sending them to friends. I also added support for projectiles, background music, and user-defined sounds to the standard 2D game engine, in order to make the final games more compelling.
In the future, I think I'd rather use a problem- or project-based approach to teaching introductory programming, but Bootstrap is the best freely available, structured curriculum I've found so far. My main frustrations with it were the written workbooks, which I eventually dropped, as mentioned above; and the fact that I only had 10 90-minute sessions, meeting once per week, to teach it. That's barely enough class time to get through all the material, even if things go perfectly smoothly. It's definitely not enough time to give students the opportunity to explore and experiment on their own, nor especially to fail and then learn from those failures, which, in my experience, is the most effective way to grok programming. However, the compressed timeline was a limitation of the after-school program I was teaching in, not Bootstrap per se.
Find out more about Bootstrap here: http://www.bootstrapworld.org/ I'm happy to give you my modified Bootstrap framework (with projectiles, etc.) and the Keynote slides I used for my lectures. The slides have very few words; they're mostly animations, diagrams, and images intended to reinforce the oral lecture.
I also "taught" a couple of Scratch sessions to middle-schoolers. You don't really teach Scratch, though; in my case, it was more like giving a 10-minute demonstration of building a simple Scratch program, and then turning the students loose, and giving them a bit of assistance when they got stuck.
Student engagement with Scratch is typically much higher than with Bootstrap, in my opinion. My Scratch sessions were each about 2.5 hrs long, and almost all of the students kept experimenting from start until finish, with 3 or 4 even staying an extra hour afterward during their free period. However, personally, I think I'd move on pretty quickly from Scratch to something capable of procedural abstraction, if a student showed a continued interest in programming after a month or two of Scratching. Among other issues, there's simply no means for students to create their own blocks in Scratch, nor to encapsulate groups of blocks into larger blocks. However, I just heard from a friend that there's a new version of Scratch coming, code-named Sage, I think, that will provide at least some of this missing functionality.
Scratch certainly requires less effort on the instructor's part than Bootstrap. Scratch includes a ton of assets, for one thing. With Bootstrap, when your student(s) come up with a game idea, you might have to help them find images, and then do some Photoshop work to extract them from their backgrounds, scale them, etc.