Back in the Day, it was BSD Unix, which used tcsh as the interactive shell and Bourne shell as the scripting shell, as tcsh had tab completion but has a scripting syntax which is harmful to sysadmins and other living things, and Bourne shell had a sane scripting language but no interactive functionality beyond cooked mode.
We developed Korn shell, Bourne-Again shell (bash), and, eventually, zsh to move beyond that idiotic experience. These days, our non-interactive scripting languages are Python, Perl, Ruby, and Ruby with a different mix of libraries, all of which have better FFI other support libraries than any shell does.
My point is, unless bish has Python-class libraries, I don't see the point of taking on the annoyance of having a scripting shell different from my interactive shell.
fish does make scripting so much saner.
- $array just does the right thing, which bash can only approximate as "${array[@]}". This alone is worth everything.
- (command) splits the output on newlines.
- Block syntax is simpler, with exception of boolean composite conditions that need awkward begin ..; end wrapping
- "everything is a command" syntax makes writing sometimes more verbose but reading easier.
- prototyping at the command line then turning into a script is easier thanks to multi-line editing with indentation and syntax highlight.
There is however the portability factor. I've used fish as my only interactive shell for at least 5 years yet I rarely write a script complex enough to justify requiring users to have fish installed. Even when I write only for myself this sits at the back of my head and biases me to #!/bin/bash...
From this perspective, "bish compiles to bash" made me immediately take note as a wise move.
That's what I was going for. Not a replacement for bash the shell, but a language that provides a bit more comfort for programmers while retaining the ability to run on any system your scripts did previously.
