Thompson and Ritchie, who carried it over from Multics to Unix. They worked on Multics, and that OS introduced the hierarchical filesystem.
DOS just copied Unix, right down to the | piping, and < > redirection, and . and .. directory links which are fake.
Navigation of a path requires that the parents be traversed before children. For instance resolving /usr/bin/ls means we locate the root directory node, then navigate through usr and bin, finally resolving to ls. The components are written in order of traversal, and that order is left to right because English is written left to right. When /usr/bin/ls is passed to the kernel, it's in a character string which is referenced by a pointer to its beginning: it's pointing at the / in /usr. It is natural to process it in that order: visiting the characters in / u s r / b ... order just requires incrementing the pointer byte by byte from the starting value.
There are other reasons to have the most major part near the beginning. A telephone number's country code and area code details coming first allows the network to begin make appropriate switching decisions before the dialing is complete.
Imagine you had to dial someone's "extension 42" before the company phone number. That extension would have to be stored somewhere, until the company's PBX picks up the call, because that extension only makes sense in the context of that switch.
Also, if we collect the absolute path of every object in the file system, and then sort it lexicographically, the parent to child order means that things in the same directories end up nicely listed together.
The computer can easily traverse in either direction. I don't know see any technical reason to list identifiers in that order. No linguistic reason either. We don't do that for addresses in the real world. We don't say "United Kingdom, London, Westminster, Downing Street 10."
Imagine if Internet domain names are arranged as file paths. To reach the BBC web site, I'd have to type in "uk.co.bb" before the computer can auto-complete. As it is, all have to do is type the letter B.
It's funny that you should say that about addresses because that's exactly how they work in Japan [0]:
> When written in Japanese characters, addresses start with the largest geographical entity and proceed to the most specific one. When written in Latin characters, addresses follow the convention used by most Western addresses and start with the smallest geographic entity (typically a house number) and proceed to the largest.
It's funny you should say that about domain names because that is how they really appeared, for the longest time, in UK e-mail addresses.
The old Sendmail had to rewrite addresses as mail was passed around (via uucp, often) to accommodate the Brits insistence on driving on the contrary side. But they invented computers, so who could tell them they were wrong?
Most European countries follow that order of precedence. Intriguingly so did technical reports for the US DoD, dropping the ordinal suffix for clarity even when spoken: 24 May.
It feels natural to me, but of course that may well be because it's all I've known.
ISO 8601 dates are formatted this way, from biggest period to smallest (e.g. 2019-10-31). It makes them universally easy to parse, and removes any confusion over the date and months parts (common issue between US and UK).
But general tendency is to go from specific to the general. That's because single name is often enough to uniquely identify something in a given context. If I say "10 Downing Street", you'd know that I'm referring to the British PM's office even if we were sitting in Palookaville Kansas. In a filesystem, that's even more true. We aren't going to have dozens upon dozens of files named "xorg.conf".
Imagine if file paths were expressed in reverse. You want to edit xorg.conf. As soon as you enter "vi xor" the shell would know enough to auto-complete it to "vi xorg.conf/X11/etc". As it is, organizing files into a logical structure actually makes them harder to find.
I'd say that's a bit of an edge case. Consider editing a file named README, index.html, .htaccess, or any number of other files which occur in many places with the same name.
The problem I see is this makes it hard to have domain-specific or optional address interpretation. Eg "foo.png=FILE?get@example.com[http]" or... something to that effect.
DOS just copied Unix, right down to the | piping, and < > redirection, and . and .. directory links which are fake.
Navigation of a path requires that the parents be traversed before children. For instance resolving /usr/bin/ls means we locate the root directory node, then navigate through usr and bin, finally resolving to ls. The components are written in order of traversal, and that order is left to right because English is written left to right. When /usr/bin/ls is passed to the kernel, it's in a character string which is referenced by a pointer to its beginning: it's pointing at the / in /usr. It is natural to process it in that order: visiting the characters in / u s r / b ... order just requires incrementing the pointer byte by byte from the starting value.
There are other reasons to have the most major part near the beginning. A telephone number's country code and area code details coming first allows the network to begin make appropriate switching decisions before the dialing is complete.
Imagine you had to dial someone's "extension 42" before the company phone number. That extension would have to be stored somewhere, until the company's PBX picks up the call, because that extension only makes sense in the context of that switch.
Also, if we collect the absolute path of every object in the file system, and then sort it lexicographically, the parent to child order means that things in the same directories end up nicely listed together.