I've recently read The Design of Kodu: A Tiny Visual Programming Language for Children on the XBox 360 (Matthew MacLaurin, POPL'11). Like me, the designers of Kodu first learned programming as children, using ROM BASIC in the home computers of the 80s (it was an Atari 800XL and then an Apple II in my case). I think this was a wonderful way to learn programming (Dijkstra's quip notwithstanding), but can children today be introduced to programming in a remotely similar manner?
Apparently not. As the paper states, "We realized very early that the kids of today have a very different context than we ourselves had in the 80s, particularly in regard to user interface and the games themselves, which often have art budgets comparable to those of the largest Hollywood films. We didn't want 21st century language for building 1980s games; instead, we felt our new language should be able to achieve the same quality of work product that kids experience in commercial console games today."
To address this goal, the team (in Microsoft Research) created Kodu as a GUI environment were kids use sensors, filters, and selectors to decide when to change the world using actuators and modifiers. A program could be something like:
1. See (sensor) - purple (filter) - move (actuator) - away (modifier)
2. See (sensor) - apple (filter) - move (actuator) - towards (modifier)
with the expected results regarding the behavior of the avatar in the game. "In the case of a purple apple, the rule to move away from purple objects will take priority" (because it appears first). More complex designs are made possible by means of pages, where an actuator can switch a "robot" (as the avatars are called) from one "page" (program) to another, in effect changing the robot's control procedure and allowing for some level of structured programming.
There are no variables in Kodu: state is stored and read from the world. Apparently, the intended way to keep state was using, for example, objects' colors; but children quickly realized that they could use the score of each robot as an integer variable.
More than anything else, this clarifies to me that programming should be taught using programming languages. I agree that console output, not to mention command-line games, is too limited for today's children. But, aiming at youth the same age I was when I first started programming (10-12 or so), I think that using a real programming language is far superior to using a toy one. My recommendation would be starting with HTML: it's not a programming language per se, but it would teach children the importance of accuracy, nesting, the implication of a simple typo on your output, the difference between a visible mistake and an invisible one, and so forth. Then, add JavaScript. There's no need for expert-level HTML and JS, mind you. The HTML would just set the ground for the JavaScript output; pick up images, or areas for text, etc. with getElementById, and then manipulate that element -- its location, size, and textual content. And input is very simple, too, using either text fields, buttons, or clickable elements with onClick events.
Just make sure you don't try to teach the children object-oriented programming using JavaScript. The language (at least in its current version) is simply not object-oriented, and seeing Java/C#/C++ programmers trying to force object-oriented design into an object-based, but not object-oriented, langauge is painful, and reminds me of the old adage about FORTRAN programmers who remain FORTRAN programmers, no matter what programming language they use.