Why Create a New Unix Shell?
Greetings!<p>First off, any person who would write either a language or a shell, now or in the future, should read your page, and in fact, should read everything about your Oil shell&#x2F;language...<p>It&#x27;s a laudable effort!<p>This page is going to my HN favorites, for future review.<p>What follows next are my thoughts about selected excerpts of text on the page (please don&#x27;t interpret as criticism, that&#x27;s not the intent):<p>&gt;&quot;You can think of a Unix shell in two ways:<p>1. As a text-based user interface. You communicate with the operating system by typing commands.<p>2. As a language. It has variables, functions, and loops. Shell programs are text files that start with #!&#x2F;bin&#x2F;sh.&quot;<p>[...]<p>&gt;&quot;Are you reinventing Perl?<p>It&#x27;s true that Perl is closer to shell than Python and Ruby are. For example, the perl -pie idiom can take the place of awk and sed. However, Perl isn&#x27;t an acceptable shell either:<p>o It doesn&#x27;t have true pipelines (of processes). I believe you have to &quot;shell out&quot; for this.<p>o It doesn&#x27;t have a concept of file descriptor state. How do you write the equivalent of my_shell_func 2&gt; err.txt, where my_shell_func can invoke both functions and external commands?<p>o Perl has a function called grep(), but the real grep is better for many problems.&quot;<p>PDS: This touches upon a historic problem, which is basically that either:<p>A) Shell designers work their way &quot;up&quot; to a programming language, in which case some elegant programming language features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly &#x2F; &quot;non-orthagonally&quot;, AKA a &quot;Kludge&quot;.<p>Or:<p>B) Language designers work their way &quot;down&quot; to supporting shell commands &#x2F; a shell subsystem -- in which case some elegant shell features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly &#x2F; &quot;non-orthagonally&quot;, AKA a &quot;Kludge&quot;.<p>Also, languages are typically too heavy in what they require typed for shell-scripters, and shells are typically too light in what they allow (and error checking&#x2F;debugging features) for programmers writing large programs...<p>If someone were to design the most ideal programming language which also can be used for shell scripting, they&#x27;d have to look at things from both perspectives, and they&#x27;d have to create a language&#x2F;shell -- completely balanced &quot;down the middle&quot; between these two paradigms...<p>Perhaps the Oil shell&#x2F;programming language -- is, or will become that middle line...<p>To that extent, I wish you a lot of luck!<p>If I were going to go down this path, I&#x27;d look at &quot;first principles&quot; (Elon Musk):<p>The greatest differentiator between shell commands and lines of code in most programming languages is the point you alluded to in your comparison with Perl:<p>&quot;o It doesn&#x27;t have true pipelines (of processes). I believe you have to &quot;shell out&quot; for this.&quot;<p>In other words, in most programming languages (unless you are using threads), you are guaranteed linear execution.<p>In a Unix shell -- because you can run multiple commands that may take varying amounts of time to complete, this guarantee is no longer present...<p>That would be the fundamental thing to keep in mind when writing this future language&#x2F;shell...<p>(A good program to test when writing this language would be a Web-server -- where the base server is a single script, and then when it detects a connection, passes this over to either a single separate command-line invoked Unix program or script comprising multiple such Unix programs linked with pipes, but the central &quot;server&quot; script has to handle a whole lot of simultaneous I&#x2F;O from multiple such separate programs (it centralizes database access!), and do this in a simple way that script programmers would be comfortable with, while guaranteeing the correct data flows...)<p>Anyway, wishing you luck in this endeavor!