Baby book

As I said earlier, I am writing a book for kids to entice some of them into the world of coding. I think I can get quite far quite quickly - kids have no pre-concieved ideas about what is hard and so won't be put off when I start talking about objects, double buffering, threading and network communications.

What language to choose?
I'm not going to write it in Java, C (or derivatives), etc - it takes too much work to do small things: lots of code, creating files, compilation, shared lib mgt, etc. Java, et al are fine for enterprise level, heavyweight or just professional coding, but not for kids to scratch together little scripty examples. I think I'm saying I want a scripting language, so what other ones are out there?

• I first thought javascript (ECMAScript really) would be a nice language, but the commandline versions of javascript I have found (on the JVM so I can re-use AWT, etc) have broken scoping rules (Rhino and FESI).


• Groovy appears to have intentionally broken scoping rules, but that's a conversation for me and a Groovy friend of mine. It's worth noting here that this is as 'far out' of the mainstream as I'm willing to go. I want a recognisably 'real' language. Groovy is right on that boundary for me.


• Lisp of some form might be nice, but I just feel some of the OO implementations are a bit of a cludge. My experience of lisp (scheme, ELisp and CLisp) was that you start from a long way back (by modern standards).


• Perl? Just no, ok?


• Python I just don't like - the whitespace thing just stops me every time. This, I know, is my fault. However, I'm aware that it offers nothing over ruby so ruby wins here.


• Smalltalk was designed to be a OO, scripty, teaching language. Here is where I think I reject it. I am not after a teaching language, I want a 'real' language that can be used for teaching, one where it is a happy accident that it is suitable for learning to code. Have you opened an smalltalk environment ever? Squeak was the one I tried. Holey moley, was it offputtingly busy?! What I objected to was the mental leap reaquired to 'see' the code behind the pretty UI. Perhaps I'm too oldschool in this respect, but I see code as a distinct artifact. Mixing it into the graphical system is interesting, but I think this confuses the issue too much.

I have a friend willing to do the artwork. I think making it visually appealing will be practically as important at the content. Or in other words, I don't think it would work if either are wrong.

What other issues will I meet? It's always good to look to another's experiences. I found this excellent introduction from Chris Pine, so I an awaiting a copy of his book from Amazon.