2008-06-28
The other reason that shells should be programmable
I gave several sensible low-level reasons why Unix shells should be programmable in WhyShellLanguages. But the higher level reason why is simpler: shells should be programmable because it helps people grow their expertise.
If doing sophisticated Unix glue things is done with a separate language, there is a huge barrier to entry; you have to learn an entirely new language before you can start doing even relatively small things. Many ordinary users are simply not going to have either the interest or the time to invest (especially when it may not be clear if they can get anything they're interested out of it).
By contrast, letting the shell be programmable in the same language that you use at the command prompt lets you grow slowly in your usual environment. Learning a little bit immediately makes you a little bit more productive (assuming that you pick the right little bits), which gives you good feedback and thus encourages more learning.
(I also believe that things are easier to learn when you can immediately apply them and thus both test and reinforce your knowledge. It's sort of like testing a program bit by bit as you write it, instead of writing it all and only then testing it at the end.)
Or in short: a programmable shell encourages starting users to become expert users by giving them a shallow learning curve with immediate rewards.
(A sub-case of this is learning how to write and customize your own dotfiles, although the more I think about it the more I suspect that most people start out with aliases and little commands.)
Note that there is a chicken and egg problem here if you have to understand how to program your shell in order to see what being able to program your shell can get you. One advantage of decent programmable shells is that it's relatively clear in advance what you get from learning a bit of shell programming; you get to wrap conditions and logic around your commands.
2008-06-06
Why shells should have small programming languages
In light of things such as Perl and Python, it is reasonable to ask why the shell should have any sort of programming environment or language at all. Why not just restrict shells to simple commands, pipelines, and redirections?
(I'm assuming here that you have a good Unix glue language around for everything that people currently write shell scripts for.)
The obvious problem is the issue of where you draw the line. Is looping over lists of files and doing something to each of them a common enough operation that you should include it? How about conditional execution, so that you can only do one thing if the previous thing succeeded?
(That's a feature that you probably want in some form, because it makes a number of things much safer in the face of potential typos and so on.)
Where the line should be depends on what sort of operations you think that people routinely perform at the command line, which depends on your user community (or target user community), which means that there is no correct answer, only lots of arguments (or different shells).
The more subtle issue is the problem of initializing the shell's environment. Dotfiles can sensibly be reasonably complex (especially in a multi-architecture and multi-Unix environment with shared home directories), so you can easily need quite a bit of expressive power (conditional checks, loops to check this and that and the other, and so on). There's ways around this, such as using an entirely separate language for this purpose, but they aren't entirely pretty.
(Limiting the complexity of what people can do in their dotfiles makes the problem worse, because it doesn't make the need go away, it just forces people to do things in a more indirect and unreadable way.)