What's wrong with learning kids Shell scripting? I think most Unix-like OS's are good for learning, behind the complex layers of abstractions lay the simple command line. Excellent for programming without any distraction.
Assuming you mean bash-like shells on Unix boxes, quite a few things:
1. Commands have arbitrary, hard-to-remember names.
2. Destructive commands tend not to issue warnings.
3. Mass destructive commands still tend not to issue warnings.
4. Did I mention that destructive commands don't tend to issue warnings?
5. Destructive commands typically can't be undone.
A system where you can do a lot of permanent damage without warning and where the names of things are mostly guesswork is a terrible environment for experimentation, and experimentation is often the best way to learn a new technology.
I meant that you should setup a simple environment, setting up a partition and chroot into it. Learn the kid to use man(1) and ed(1) and after that let him/her play around. I heard someone doing this with his 5 year old kid on the OpenBSD mailing-list, that kid will probably be able to write quite useful scripts in a few years.
Why should you teach a child ed(1), instead of any other text editors?
In my opinion , it is one of the most sadistic common text editors in existence, and has been for several decades.
To be fair, Python's shutil.rmtree() won't give you any warnings either.
Sure, and that's why I don't think modern general-purpose programming languages like Python are a particularly good substitute for the BASICs of old as a default environment.
If the idea is to encourage kids to learn more about the technology they're using, one of the most basic requirements is a safe system they can use without any danger of causing serious damage.
And there's a limit on your ability to destroy stuff if you're not running as root.
That assumes your system has a concept of root, which in turn assumes your system has a concept of users at all and a robust security model. I'm not sure any of those things is necessary, or even desirable, for the kind of system we're thinking about here. I think the correct requirement is "User can not cause any permanent damage", and if things like Linux or Windows or Python or Ruby can't meet that requirement, then they simply aren't the tools we're looking for in this particular context.
You could just set up an isolated system with nothing you care about holding onto for them. Destructive commands would, at worst, require a full wipe and re-image and probably a short conversation about what the fuck just happened.
The most productive time in my educational career was when I built PCs, loaded every OS I could find, and destroyed them. As long as it isn't the same system as your tax records, its great.
Nowdays with VMs, snapshots, and partition editors, learning can be accelerated.
all of the above are great for well supported kids to learn about firsthand. resillience and perseverance are great traits to acquire young, especially when coupled with a healthy awareness of your own fallibility.
Assuming you mean bash-like shells on Unix boxes, quite a few things:
1. Commands have arbitrary, hard-to-remember names.
2. Destructive commands tend not to issue warnings.
3. Mass destructive commands still tend not to issue warnings.
4. Did I mention that destructive commands don't tend to issue warnings?
5. Destructive commands typically can't be undone.
A system where you can do a lot of permanent damage without warning and where the names of things are mostly guesswork is a terrible environment for experimentation, and experimentation is often the best way to learn a new technology.