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.
