I have used Fish before, though we are talking 10-ish years ago, and there is a lot to like about it. However it didn't resonate with me personally. I guess you could describe my feelings towards it as sort of an "uncanny valley" where it was too different to Bash to be compatible while being too similar to Bash to be worth the effort learning. So the whole experience felt more jarring than enlightening. Again, this is just a personal feeling and not a comment on their technical accomplishments. For example I was always impressed by just how polished Fish's interactive shell is.
When designing murex (the shell I now use daily) I wanted to go one step further and say "If I'm abandoning Bash compatibility then what new things can I bring to the table". This will no doubt alienate a lot of new users that might prefer Fish's "like Bash but better" approach though. Which is fine, there's more than enough room for both shells to exist.
Obviously, syntax preferences in programming languages are very personal, so what someone considers to be simple and beautiful, someone else may consider as complex and ugly.
Nevertheless, in my opinion, the right way to improve the "if ... fi" POSIX shell syntax is not by adding tons of superfluous curly braces, but by removing the redundant square brackets and the redundant semicolon (all of which have historical reasons for their presence).
With those changes, you have the minimal fully-bracketed syntax for a conditional statement, e.g. (if ... then ... elif ... then ... else ... fi).
If you do not like these keywords, that is fine, you should replace them with other keywords or symbols.
For example, I like concise syntax, so I replace those keywords with certain Unicode symbols, i.e. mathematical angular brackets instead of if and fi, section sign instead of elif and else, and left arrow instead of then.
It does not matter what keywords or symbols you like, but both the ease of writing and the ease of reading are improved when each kind of program control structure uses distinct delimiters, not just the same curly braces for everything, and also when there are no redundant delimiters, e.g. in C and derived languages there are a very large number of redundant parentheses, which are needed because the curly braces are optional. Had the curly braces been mandatory in C, the parentheses from if, switch, while, for would have been deleted, which would have lead to easier to read and write programs in the common case, when braces are used.
The final syntax presented has an almost double number of delimiters than needed, presumably because the curly braces are reused for various other purposes in the complete murex shell syntax.
Trying to use too few distinct symbols or keywords is guaranteed to increase the number of redundant delimiters.
Maybe the Algol 68 method of inventing keywords like fi, esac, od, was not the most inspired, but the principle of using different kinds of delimiters for each distinct purpose was, and is, sound.
I agree to an extend and in fact this is what murex already does. Superficially it looks like C (minus semi-colons) but the parentheses are the tokens that replace the ALGOL style then, else and fi keywords. What murex does do is allow those keywords to be optionally included for readability. So all the docs will say
if { = 1==2 } then {
err 'math is broken'
} else {
out 'math works'
}
as it's easy to read but really the then and else keywords are just ignored. So the same one liner is perfectly valid
if{= 1==2} {err 'math is broken'} {out 'math works'}
So you do have the terseness in the interactive shell that you're requesting.
The curly braces do serve an important significance to the parser in murex. Because everything is defined as a function, it means `if` is a builtin and the curly braces are read like quotation marks denoting the start and end of executable parameters (like a subshell but minus the forking). So the `if` command gets the arguments passed like so (pseudo-JSON):
> if{= 1==2} {err 'math is broken'} {out 'math works'}
So you ended up with kind of like TCL's choices (`then`, `else`, `elseif` are optional; prefix expressions with `=` (`expr` in TCL's case, although it's implied in `if`, `while` conditionals) )
Great answer!, and… well, I’m adding it to the article. In my head :)
My experience with fish is quite different, and that’s exactly why I find this discussion so good.
Regarding how shells are made more than the shells themselves, I wish to point to the design document itself in case you haven’t had the chance to read it yet; It’s one of the better texts on this sort of thing. I’d be interested in your take on it if one is available :)
I like the layout of the design document and I might steal this page idea myself. However I don't agree with all of the contents:
> The law of orthogonality
For better or for worse I went the other way and crammed murex full of builtins. Most builtins are single purpose too.
Rational: while it creates additional work learning murex it does make pipeline more descriptive
> The law of responsiveness
This I do agree with an murex does a lot of tasks asynchronously for exactly the same reasons too
> Configurability is the root of all evil
I actually don't disagree with their point on principle but I think a better stance should be "Defaults should not leave most users itching for configurability" because I think configurability is a good thing however a product should ship already configured so that users aren't left having to enable features they want.
The early versions of murex came with features turned off so it behaved a lot more like Bash. Then I realised nobody is going to enable spellchecking, syntax highlighting, etc because nobody is going to know it is there. So now most features are enabled by default.
> The law of user focus
The description I agree with, the examples I do not. You don't need to remove features to make something user focused. You just need to make those features usable and discoverable.
When designing murex (the shell I now use daily) I wanted to go one step further and say "If I'm abandoning Bash compatibility then what new things can I bring to the table". This will no doubt alienate a lot of new users that might prefer Fish's "like Bash but better" approach though. Which is fine, there's more than enough room for both shells to exist.