It's a reminder of how archaic the systems we use are.
File descriptors are like handing pointers to the users of your software. At least allow us to use names instead of numbers.
And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.
It should be a lesson to learn on how simple, logical and reliable tools can last decades.
> At least allow us to use names instead of numbers.
You can for the destination. That's the whole reason you need the "&": to tell the shell the destination is not a named file (which itself could be a pipe or socket). And by default you don't need to specify the source fd at all. The intent is that stdout is piped along but stderr goes directly to your tty. That's one reason they are separate.
And for those saying "<" would have been better: that is used to read from the RHS and feed it as input to the LHS so it was taken.
The conveniences also mean that there is more than ~one~ ~two~ several ways to do something.
Which means that reading someone else's shell script (or awk, or perl, or regex) is INCREDIBLY inconvenient.
I quite like how archaic it is. I am turned off by a lot of modern stuff. My shell is nice and predictable. My scripts from 15 years ago still work just fine. No, I don't want it to get all fancy, thanks.
Who do you imagine the users were back when it was being developed?
The programmers were the users. They asked. They said it was ok.
Wait until you find out where "tty" comes from!
> bash's syntax is so weird
What should be the syntax according to contemporary IT people? JSON? YAML? Or just LLM prompt?
At the time, the users were the programmers.