You can make a program to convert it to some human-readable number then. You have to do this because it's binary anyways, so you're either representing it as oc

You can make a program to convert it to some human-readable number then. You have to do this because it's binary anyways, so you're either representing it as octal, hexadecimal or binary. I don't know about you, but if I am trying to reason about hexadecimal numbers then I just separate it into 0xDEADBEEF = D*16^7 + E*16^6 + A*16^5 + D*16^4 + B*16^3 + E*16^2 + E*16^1 + F*16^0. The endianness only changes the order of the bytes I start reading at. What we ought to do is make a new prefix for reading the hexadecimal numbers in little-endian order like 0xDEADBEEF = 0yEFBEEDDE. Of course, this doesn't really fix the problem (wanting to read the number with smaller symbols first) as bytes are still considered to be in big endian if you consider the semantics about left/right shifts, which play on our preconceived notions of big endianness in everyday decimal math. You would want a system where everything is treated little-endian (bits within bytes, bytes within arrays)