Improving on the Unix shell
Yesterday I ran across Askar Safin's blog post The Collapse of the UNIX Philosophy. Two quotes from the post stood out. One was from Rob Pike about the Unix ideal of little tools that each do one job:
Those days are dead and gone and the eulogy was delivered by Perl.
The other was a line from James Hague:
" if you romanticize Unix, if you view it as a thing of perfection, then you lose your ability to imagine better alternatives and become blind to potentially dramatic shifts in thinking.
This brings up something I've long wondered about: What did the Unix shell get right that has made it so hard to improve on? It has some truly awful quirks, and yet people keep coming back to it. Alternatives that seem more rational don't work so well in practice. Maybe it's just inertia, but I don't think so. There are other technologies from the 1970's that had inertia behind them but have been replaced. The Unix shell got something so right that it makes it worth tolerating the flaws. Maybe some of the flaws aren't even flaws but features that serve some purpose that isn't obvious.
(By the way, when I say "the Unix shell" I have in mind similar environments as well, such as the Windows command line.)
On a related note, I've wondered why programming languages and shells work so differently. We want different things from a programming language and from a shell or REPL. Attempts to bring a programming language and shell closer together sound great, but they inevitably run into obstacles. At some point, we have different expectations of languages and shells and don't want the two to be too similar.
Anthony Scopatz and I discussed this in an interview a while back in the context of xonsh, "a Python-powered, cross-platform, Unix-gazing shell language and command prompt." While writing this post I went back to reread Anthony's comments and appreciate them more now than I did then.
Maybe the Unix shell is near a local optimum. It's hard to make much improvement without making big changes. As Anthony said, "you quickly end up where many traditional computer science people are not willing to go."
Related post: What's your backplane?