They all have reasons.

> * Significant whitespace in surprising ways (a=1 vs a = 1 or spaces following square brackets)

Variables in the shell are nicely coupled with environment variables. As a feature, you can do:

  a=1 b=2 cmd

to concisely assign environment variables for a single command. How would you recommend that be redone? You'd need additional cumbersome syntax if you want whitespace to not be significant, and that sucks for a language meant to be used mostly interactively:

  a = 1, b = 2: cmd

Because shell languages are meant primarily to be used interactively, we want to be very light on syntax. We don't want to have to say `var` or something before our variable definitions. We don't want to have more syntax than we absolutely need for our calls. Nothing like `cmd(a,b)`. cmd can be any string. They're just executable files in some directory. We want to include as many of them as possible, and their arguments can be anything, including `=`. Commands get as much freedom as possible over how they're called to fit as many needs as possible. So, how do you differentiate between calls and variable assignments?

Under those criteria, the current situation of statements being words separated by whitespace and the first words having `=` in them being assignments seems like the ideal solution.

> * Word splitting

Makes it easier to build commands without working syntax heavy complex data structures. Here's an example where word splitting is useful:

  sudo strace -f $(printf " -p %s" $(pgrep sshd))

> * No data structures of note, nor any way to create them in any sort of non-hacky way

Complex data structure lead to more heavyweight syntax, and part of the appeal of shell languages is that everything is compatible with each other because everything is text. If you add data structures then not everything is text.

> * No data types, really, for that matter

Same point as above. Everything being text leads to increased compatibility. I wouldn't want to have to convert my data to pass it around.

That said, you could say that there are weak-typing semantics, since you can do `$(( $(cmd) + 2 ))`, for example.

> * Can't really deal with binary data

Because everything is text to encourage easily inspectable data exchange and compatibility between programs.

That said, while it's not advisable to do it, binary data is workable if you really need to do that. Pipes don't care. I can pipe music from ssh to ffmpeg to mpv, if I want. One just needs to be careful about doing text-things with it, like trying to pass it as a command argument. $() will remove a terminating newline if present, for example. That makes sense with text, but not with binary data.

> * Awful error handling

I don't get this. I think bash has very good error handling. Every command has a status code which is either no error or a specific error. Syntax like `while` and `if` work by looking at this status code. You can use `set -e` and subshells to get exception-like behavior. Warnings and error messages are, by default, excluded from being processed through pipes. What do you find lacking?

> * Weak math

Sure. I'll give you that bash doesn't support fractional numbers natively. zsh does support floating point.

> * Weird scoping rules

It's dynamic scoping, and it does have some advantages over the more commonly seen static scoping. You can use regular variables to setup execution environments of sorts. This somewhat relieves the need to pass around complex state between functions. It's kind of a different solution to the same problem that objects in OOP address.

The only problem is that static scoping became so popular that people now are generally not even aware that dynamic scoping exists or how to use it, so it's now not recommended to use it to not confuse people that don't know that part of the language they're using.

About that, I wish people would just learn more of the languages they use, and not expect every language to work the same, as they're not all meant for the same purposes or designed by the same criteria.

I think bash is fine as a shell and I understand why the syntax is the way it is, I'd just never use it for anything beyond a one liner or a list of commands. All my points were about its weaknesses for scripting, ie, anything that looks and acts like a program. There's basically no reason to use it that way when there are a million better programming languages that are ubiquitous and relatively small.

It still seems better suited when the script is mostly about running executables and passing their inputs and outputs between each other. As an example, I think `pass` was very nicely chosen to be done in bash. I don't think there would've been any benefit in doing it in a non-shell language.

I also think that if a program's job is by good proportion about sourcing shell-scripts to e.g. prepare an environment for them and/or manage their execution, it's also a good idea to make that program in the same shell language. As an example of this, I think Archlinux's `makepkg` was best done in bash.

On why make a program that's about sourcing shell scripts at all, the shell is the one common language all Unix-based OS users know in common, pretty much by definition, so it makes it a good candidate for things like the language of package description files. Besides the fact that software packaging of any language involves the shell, you kind of expect people that call directly on `makepkg` to also want to be able to edit these files, so making them in the language that they're most likely to know is good.