WebAssembly

As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++.

quake3 has been compiling c code into portable mods since 18 years ago. they could have just used that.

>>11
because this is the opposite of how we read numbers in real life, where digit n has value 10¹ and digit 1 has value 10ⁿ. the way we do it IRL might not be logical but we're used to it and trying to change it to a 'better' approach would just end like metric time units

>>11
Honestly I have to agree with cudder on this one. Little endian is far more intuitive in that for example a pointer to a larger integer will still be valid if used as a pointer to a smaller integer so long as the value is less than the max range of the smaller integer type. With big endian it just becomes zero.

The only thing even slightly counter intuitive about little endian is that the data looks "backwards" when you view it in a hex editor, but that's only because humans also write numbers in "big endian", which is dumb and backwards too. I feel that the number "1488" should actually be written "8841", because that's how we write words: the first letter comes first. If I want to make a word longer I can keep sticking letters to the end of it without changing the meaning of the preceding letters, but with the current "big endian" system sticking extra digits onto the end also changes the meaning of all the preceding digits by powers of ten, which is totally backwards and weird when you think about it.

>>13
Writing systems are big-endian because the most significant letter comes first. The reason the meaning of preceding letters in a word doesn't change when you append new ones to it is because the "radix point" is located before the word. The same applies to decimal numbers: the first 3 in 0.3141 doesn't change even if you continue the number to infinity.