3 ms·

Shell languages are defined by their terseness. The author misunderstands how important this is: https://docs.google.com/presentation/d/11vZzXCfAA0aOFAuHA0nAvA

by eggie 11y ago

Shell languages are defined by their terseness. The author misunderstands how important this is: https://docs.google.com/presentation/d/11vZzXCfAA0aOFAuHA0nAvAzALGFGCH-dqHxx6XMgbk8/preview?sle=true&slide=id.ga54359adc_1_218 https://docs.google.com/presentation/d/11vZzXCfAA0aOFAuHA0nA... The author has created a radically "better" shell language which is twice as verbose as bash. In the space of human-computer interaction where shell languages lie, this is tantamount to total failure. The worst parts of shell are the flow control structures (if/else...). If only we could improve this without throwing out the entire system. Else we will lose the benefits of the ultra-terse and completely decentralized "language" that is unix shell.

hyperpape 11y ago
This is mostly true, and it doesn't look like this is the solution. My belief is any solution needs to be built from the ground up as a language for shell use, not adapting Python/Scala/Haskell to shell use. However, there is some non-zero amount of verbosity that would be worth trading for better control flow, composability, data structures, etc. As long as you can do simple operations and pipes with the same syntax | grep foo cp * path/ rm -rf it's ok if some operations are more verbose in exchange for that. Programmers don't live in bash, and deal with the pain points of switching between bash and an actual programming language on a regular basis. I know I'm there. A change that sometimes is more verbose but lets you do more things in shell would still have benefits. You might not win over the people who are bash experts, but you could still produce a better tool for many people.
klibertp 11y ago
I didn't check it out yet, but I think Tulip (http://www.jneen.net/posts/2015-07-29-tulip-language-updated http://www.jneen.net/posts/2015-07-29-tulip-language-updated) has a great potential in this space.
sambe 11y ago
The author explicitly states terseness is a goal, and compares alternatives' overhead to bash. However, he recognises there is a limit whilst remaining safe/close to Scala. I don't agree control structures are a major problem. There are subtle differences between correct and incorrect expressions, and they are not checked at "compile" time.
stcredzero 11y ago
How about an interpreter that executes from an AST, which can also re-generate formatted source in two forms, "revealing" and "terse"? One should be able to also write a debugger that can switch between these modes in real-time.
101914 11y ago
Beautiful response to a recurrent misunderstanding. "Shell languages are defined by their terseness." It is common to see people put a layer of verbosity on top of the Bourne shell (or system(3)) to make "a new shell". It is also very common to see people put a layer of abstraction on top of a large, verbose scripting language and claim the result to be a new, "terse" language (with all the power of the shell). But what I like about the Bourne shell is that it is built from only C. And it does not add too much verbosity. It is, as you say, defined by its terseness. There is also terseness in the roff-like typesetting languages, assembly languages, FORTH, k/q, etc. Compared to k/q, sh is verbose. For me, verbosity means loss of power and loss of time. I am glad there are terse languages. They may never again be popular but I think they will always exist. "The worst parts of the shell are the flow control structures..." For some reason I dislike if/then/else. Instead I make heavy use return values, ||, test(1) and case/esac. I always wished Bourne's shell (cf. Joy's C shell) made use of more C operators. There's a file called arith_lex.l in the Almquist sh source but these operators are not used in the sh language. I would switch to the Plan 9 shell but Bourne sh remains more useful due to its ubiquity.

by eggie 11y ago

hyperpape 11y ago

This is mostly true, and it doesn't look like this is the solution. My belief is any solution needs to be built from the ground up as a language for shell use, not adapting Python/Scala/Haskell to shell use. However, there is some non-zero amount of verbosity that would be worth trading for better control flow, composability, data structures, etc. As long as you can do simple operations and pipes with the same syntax | grep foo cp * path/ rm -rf it's ok if some operations are more verbose in exchange for that. Programmers don't live in bash, and deal with the pain points of switching between bash and an actual programming language on a regular basis. I know I'm there. A change that sometimes is more verbose but lets you do more things in shell would still have benefits. You might not win over the people who are bash experts, but you could still produce a better tool for many people.

klibertp 11y ago

I didn't check it out yet, but I think Tulip (http://www.jneen.net/posts/2015-07-29-tulip-language-updated http://www.jneen.net/posts/2015-07-29-tulip-language-updated) has a great potential in this space.

sambe 11y ago

The author explicitly states terseness is a goal, and compares alternatives' overhead to bash. However, he recognises there is a limit whilst remaining safe/close to Scala. I don't agree control structures are a major problem. There are subtle differences between correct and incorrect expressions, and they are not checked at "compile" time.

stcredzero 11y ago

How about an interpreter that executes from an AST, which can also re-generate formatted source in two forms, "revealing" and "terse"? One should be able to also write a debugger that can switch between these modes in real-time.

101914 11y ago

Beautiful response to a recurrent misunderstanding. "Shell languages are defined by their terseness." It is common to see people put a layer of verbosity on top of the Bourne shell (or system(3)) to make "a new shell". It is also very common to see people put a layer of abstraction on top of a large, verbose scripting language and claim the result to be a new, "terse" language (with all the power of the shell). But what I like about the Bourne shell is that it is built from only C. And it does not add too much verbosity. It is, as you say, defined by its terseness. There is also terseness in the roff-like typesetting languages, assembly languages, FORTH, k/q, etc. Compared to k/q, sh is verbose. For me, verbosity means loss of power and loss of time. I am glad there are terse languages. They may never again be popular but I think they will always exist. "The worst parts of the shell are the flow control structures..." For some reason I dislike if/then/else. Instead I make heavy use return values, ||, test(1) and case/esac. I always wished Bourne's shell (cf. Joy's C shell) made use of more C operators. There's a file called arith_lex.l in the Almquist sh source but these operators are not used in the sh language. I would switch to the Plan 9 shell but Bourne sh remains more useful due to its ubiquity.