Big-endian is better than little-endian

More evidence in favor of big-endian: In modern Hebrew and Arabic, numbers are written in the same direction as in English: e.g. 

.שטחה של המדינה הוא 22,072 קמ"ר 

As a native English speaker (and marginal Hebrew reader), I read each word in that Hebrew sentence right-to-left and then read the number left-to-right.

I never considered the possibility that native Hebrew speakers might read the number from right to left, in a little-endian way. But my guess is (contra lsusr) nobody does this: when my keyboard is in Hebrew-entry mode, it still writes numbers left-to-right.^[1] 

This indicates that even when you give little-endian an advantage, in practice big-endian still wins out.

1. ^{^}

   I also tested in Arabic-entry mode, and it does the same even when using the Eastern Arabic numerals, e.g ١٢٣٤٥٦٧٨٩. 
   
   It's hard to Google for this, but this indicates that modern Arabic also treats numbers as left-to-right big-endian [I just verified with an Arabic speaker that this is indeed the case]. It's possible this was different historically, but I'm having a hard time Googling to find out either way.

How does a little endian do a decimal point? Do they put the fractional part of the number at the beginning (before the decimal) and the integer part afterwards? Eg.  123.456  becomes  654.321?  So just like all integers in big-endian notation can be imaged to have a trailing ".0" they can all be imagined to have a leading "0." in little-endian?

The way we do it currently has the nice feature that the powers of 10 keep going in the same direction (smaller) through a decimal point. To maintain this feature a little-endian requires that everything before the decimal point is the sub-integer component. Which has the feature lsusr doesn't like that if we are reading character by character the decimal forces us to re-interpret all previous characters.

[Edited to get the endians the right way around]

AFAIK, Indians used the little endian notation. Arabs reversed it since they were writing from left to right, but the Europeans did not reverse what the Arabs did. Today of course Indians follow the west in using big endian, but the little endian practice reflects in, for instance, the ka-ṭa-pa-yā-di  system used in Indian musicology ( https://en.wikipedia.org/wiki/Katapayadi_system ).

One aspect neither of you have explicitly addressed is the speaking of numbers; speaking, after all, predates writing.  We say "one billion, four hundred twenty-eight million, [...]".

Given that that's what we say, the first two pieces of information we need are "one" and "billion".  More generally, we need to get the first 1-3 digits (the leftmost comma-separated group), then we need the magnitude, then we can proceed reading off all remaining digits.

Given that the magnitude is not explicitly written down, we get it by counting the digits.  If the digits are comma-separated into groups of 3 (and "right-justified", so that if there are 3n+1 or 3n+2 digits, then the extra 1-2 are the leftmost group), then it's generally possible to get the magnitude from your "peripheral vision" (as opposed to counting them one by one) for numbers less than, say, 1 billion, which are what you'd most often encounter; like, "52" vs "52,193" vs "52,193,034", you don't need to count carefully to distinguish those.  (It gets harder around 52,193,034,892 vs 52,193,034,892,110, but manually handling those numbers is rare.)  So if getting the magnitude is a mostly free operation, then you might as well just present the digits left-to-right for people who read left-to-right.

Now, is it sensible that we speak "one billion, four hundred twenty-eight million, [...]"?  Seems fine to me.  It presents the magnitude and the most significant digits first (and essentially reminds you of the magnitude every 3 digits), and either the speaker or the listener can cut it off at any point and have an estimate accurate to as many digits as they care for.  (That is essentially the use case of "partially running the algorithm" you describe.)  I think I'd hate listening to "six hundred sixty three, six hundred twenty-seven thousand, four hundred twenty-eight million, and one billion", or even suffixes of it like "four hundred twenty eight million and one billion".  Tell me the important part first!

I think that it is obvious that Middle-Endianness is a satisfactory compromise between Big and Little Endian. 

More seriously, it depends on what you want to do with the number. If you want to use it in a precise calculation, such as adding it to another number, you obviously want to process the least significant digits of the inputs first (which is what bit serial processors literally do). 

If I want to know if a serially transmitted number is below or above a threshold, it would make sense to transmit it MSB first (with a fixed length). 

Of course, using integers to count the number of people in India seems like using the wrong tool for the job to me altogether. Even if you were an omniscient ASI, this level of precision would require you to have clear standards at what time a human counts as born and at least provide a second-accurate timestamp or something. Few people care if the population in India was divisible by 17 at any fixed point in time, which is what we would mostly use integers for. 

The natural type for the number of people in India (as opposed to the number of people in your bedroom) would be a floating point number. 

And the correct way to specify a floating point number is to start with the exponent, which is the most important part. You will need to parse all of the bits of the exponent either way to get an idea of the magnitude of the number (unless we start encoding the exponent as a floating point number, again.)

The next most important thing is the sign bit. Then comes the mantissa, starting with the most significant bit. 

So instead of writing 

The electric charge of the electron is $-1.602176634\times {10}^{-19}C$.

What we should write is:

The electric charge of the electron is $C\times {10}^{-19}\times -\mathrm{1.602176634.}$

Standardizing for a shorter form (1.6e-19 C --> ??) is left as an exercise to the reader, as are questions about the benefits we get from switching to base-2 exponentials (base-e exponentials do not seem particularly handy, I kind of like using the same system of digits for both my floats and my ints) and omitting the then-redundant one in front of the dot of the mantissa. 

Interestingly enough, the terms "big-endian" and "little-endian" were actually coined as a way of mocking people for debating this (in the context of computer byte order).

What if you are not a person, but a computer, converting a string into an integer? In that case, having a simpler and faster algorithm is important, having to start with only the beginning of a string (what the user has typed so far) is plausible, and knowing the number's approximate value is useless. So in this case the little-endian algorithm is much better than the big-endian one.

For the most part this is irrelevant. If you are a computer with only partial input, recieving the rest of the input is so much slower than parsing it that it literally does not matter which algorithm you use. If you have all the input, either is equally fast. Also, most of the complexity is going to be validating the input and handling edge cases (e.g commas Vs decimal points), not keeping track of the total.

There could be some weird edge cases, where you're reading a huge number, for some reason stored as a string, in a known format, don't require validation, from an extremely fast storage mechanism, e.g. RAM or an SSD. In that case you might care about performance of keeping track of the running total, but weird edge cases shouldn't decide which format to use (and in practice I guess they'd both be essentially identically fast here too).

Computers also need to decide whether to use big Indian or little Indian for their native representation of numbers. But either way they'll be using specialized hardware to operate on them, and both will be equally fast (and for the most part invisible to the user).

The other big-endian algorithm is the one I observe myself as usually using. For "321", it is:

• Count the digits (three), and convert that into an order of magnitude (one hundred). (Running total: ??? hundred ???.)
• Read the first digit, multiply it by its order of magnitude (one hundred), and add it to the total. (Running total: three hundred ???.)
• Read the second digit, multiply it by its order of magnitude (ten), and add it to the total. (Running total: three hundred and twenty ???.
• Read the third digit, multiply it by its order of magnitude (one), and add it to the total. (Arriving at three hundred and twenty one.)

I generally agree, except I find words like "multiply" and "add" a bit misleading to use in this context.  If I read a number like 3,749,328, then it's not like I take 3 million, and then take 7, multiply by 100,000, and get 700,000, and then perform a general-purpose addition operation and compute the subtotal of 3,700,000.  First of all, "multiply by 100,000" is generally more like "Shift left by 5 (in our base-10 representation)"; but moreover, the whole operation is more like a "Set the nth digit of the number to be this".  If this were a computer working in base 2, "set nth digit" would be implemented as "mask out the nth bit of the current number [though in this case we know it's already 0 and can skip this step], then take the input bit, shift left by n, and OR it with the current number".

(In this context I find it a bit misleading to say that "One hundred plus twenty yields one hundred and twenty" is performing an addition operation, any more than "x plus y yields x+y" counts as performing addition.  Because 100, by place-value notation, means 1 * 100, and 20 means 2 * 10, and 120 means 1 * 100 + 2 * 10, so you really are just restating the input.)

Also, I might switch the order of the first two steps in practice.  "Three ... [pauses to count digits] million, seven hundred forty-nine thousand, ...".