From a design standpoint: Because the ergonomics of shells and regular programming langauges are very different. 99% of your interactions with a shell is going to be single commands, or short piped chains. Economy of keystrokes is something that a lot of people want here, which is why cd and ls are both that short to type. Most programming languages require at least () to run commands, since not requiring that seems sloppy. This makes your two most common interactions twice as long to type.

Shells have also been built to help glue applications together, and are more concise for the easy versions than most programming languages, sometimes heavily so. Most programming languages, (outside of maybe perl and ruby), don't make this use case anywhere close to their top priority, but shells do, trading off other things like a simple syntax for bitwise OR.

In another sense, shells are exactly what you describe, it just happens that the most popular languages for them happen to be sh/bash/zsh/fish etc, which make a different set of tradeoffs than the 'traditional' programming languages.

I'm only partially aware of the history standpoint. My understanding is that before awk, shells (sh, mostly, IIRC) were about the only scripting level languages on various Unixen.

General programming languages and shells have different priorities. Specifically a shell programming language should be designed to make launching external applications and processing their output the top priority. The language also needs to focus on easy of interactive input, so much so that the repl and the language or somewhat coupled. You wouldn't have a command in a general purpose programming language to execute the same line of code as you did 5 lines ago, that would be worse than goto. However, in a shell, such a thing sounds nice. The shell also needs to make it convenient to deal with some OS level objects, such as files. This is where glob syntax comes in handy.

This all cascades to make a language that looks much different than you would want to write a full application in. One of the primary reasons is because of how shells need to handle strings. It is much more convenient to not type out quotes around string literals and it is nice to have syntax to reference environment variables, files, previous commands, etc. This leads to extremely complex quoting and expansion rules in most shells. It is not intuitive, but once learned it makes for a great interactive experience (compared with traditional languages).

Like Xonsh? http://xon.sh/

Previously discussed two years ago here: (https://news.ycombinator.com/item?id=9207738)

TempleOS does just that. What you type at the command line is the TempleOS systems language (Holy-C if I recall), it's compiled and executed. The syntax of Holy-C is such that it's not too onerous as a shell language.

I like the answer yumaikas gave. I would say that the shell IS what you're saying: a REPL for a programming language. But it is a weird programming language.

The language has evolved with compatibility since the original release in 1971, before it had loops, conditionals, or functions. That's before yacc and probably before some common parsing algorithms were even invented. It is a proper programming language by now, but it just feels old and crufty.

I think it needs a few more OS bindings as well. The "test -f / -d" stuff is a little impoverished.