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.

See https://en.wikipedia.org/wiki/Path_(computing)#Representatio... for a very incomplete list of examples.

Also "." was extremely common, used on large DEC systems (RSX, VMS) and Tandem/NonStop as home systems like RISC OS.

Multics and VOS use '>' as the separator (and '<' to indicate the parent).

The Multics-style paths really are the cleanest, in my opinion.

Edit: We run the Public Access Multics system at https://ban.ai/

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.

[0] https://en.wikipedia.org/wiki/Japanese_addressing_system

> We don't do that for addresses in the real world. We don't say "United Kingdom, London, Westminster, Downing Street 10."

That's not a universal rule. It completely depends on the language. For example in Farsi (Persian) that is exactly how addresses are expressed.

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?

JANET NRS worked that way: https://en.wikipedia.org/wiki/JANET_NRS

But we do say "May 24th at 18:50".

I could technically say "10 to 7 in the evening on the 24th day of May" but everyone would look at me like I'm nuts.

> on the 24th day of May

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.

And then ISO says 2019-05-24 18:50

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).

>It makes them universally easy to parse

Don't you mean easy to sort?

If not, what makes YYYY-MM-DD any easier to parse then MM/DD/YYYY?

I meant both, actually.

The problem with MM/DD/YYYY is that outside of the US it may be perceived as DD/MM/YYYY.

Ah you were using "parse" in the non-technical sense. Thick of me not to have considered that possibility. Thanks for the clarification.

You could type "bb" to find it even if it were "www.bb.co.uk".

Completion cannot be anchored to one end of the URL; users would find that frustrating.

When users are searching for a URL by means of a keyword embedded in that URL, it could be anywhere in that URL.

There are real world cultures that use general-to-specific for addresses

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.

Actually, that could still work:

  > in<TAB>
  index.html@.
  init.sh@..
  index.html@foobar@..
  ...
  inputrc@etc@/

The problem I see is this makes it hard to have domain-specific or optional address interpretation. Eg "[email protected][http]" or... something to that effect.

> The problem I see

Come to think of it, that also breaks option escaping in glob et al:

  ./--kill=everything
  vs
  --kill=everything@.

That makes the hierarchy sortable. Same applies to dates - you can sort 2019-05-24, but not something like 5/24/2019.