I've been wanting the same for Ruby, which I think is superior to Python in its syntax, clarity, and readability. I'd settle for a Ruby interpreter in every browser.
As for whether it makes sense to develop the appearance of everything being in Python so that kids can hack it up: you'd be better off introducing them to Scratch, Lego Mindstorms, the Arduino and have them participate in Science Olympiads. There is no modern equivalent of what we grew up with.
emacs as a login shell.... I wonder if anyone actually does that :)
Of course, in those days, everything was simpler, and for all the benefits that the modern, heterogeneous technology landscape offers us, I do think we’ve lost something by trying to make everything do everything for everyone while talking to everything else.
The people best placed to fix that are the ones who control both the hardware and the software foundation running on it, but sadly, the most obvious examples like Apple and the games console makers seem to want just about the most locked-down, developer-hostile environments in computing history.
That all said, today’s kids have the benefits of the Internet and the vast potential it offers for teaching, learning, sharing and collaborating, all on a scale we couldn’t even dream of when I was first learning to program. I wonder whether that ecosystem combined with recent hardware developments like the Raspberry Pi might offer enthusiastic youngsters a very different experience but one that ultimately encourages their interest as well or better than what we had in my generation.
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.
And there's a limit on your ability to destroy stuff if you're not running as root.
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.
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.
Nowdays with VMs, snapshots, and partition editors, learning can be accelerated.
When teaching an intro to programming, my curriculum still uses this "command shell" form. Of late, nigh unto no students have seen it, and I have to teach it as a new concept - a problem as it's more obsolete than new. Soon we'll have to give up on it as a starting point, saving it for more advanced students. GUIs rule now; beginners don't grok a text prompt.
Maximite (http://geoffg.net/maximite.html) - single IC computer running BASIC with 8 colours on VGA.
My idea is mix https://tablib.readthedocs.org/en/latest/ as data exchange, python, ipython?, https://pypi.python.org/pypi/httpie/ (as example of the kind of commands), and termkit ideas on display, interface.
So, each command could do something like:
return 'json, xml, cvs'
return 'json, xml, cvs'
def run(self, input):
But the problem is that do this is hard, take time, and to be useful, require rewrite a lot of basic unix functionality (however, a compatibility can be archived, as with ipython !command) and perhaps a custom language/interpreter to make it usable.