3 ms·
A byte-code based on Javascript VMs would be less useful than you might think. For many years people who have tried to build dynamic languages on Java have had
by CJefferson 14y ago
A byte-code based on Javascript VMs would be less useful than you might think.
For many years people who have tried to build dynamic languages on Java have had to go through horrible pain to build their languages, and not gained the performance they would want -- only the recent addition of invokeDynamic have finally allowed fast implementations.
Personally, I would hope any browser bytecode would have big integers as a primitive, as implementing them in dynamic language is very slow. However, no Javascript byte code would have big integers, as they aren't in Javascript!
- bunderbunder 14y agoWhat Javascript's capable of would really only need to be a starting point. I certainly wouldn't want to limit what's possible to what Java or Javascript are capable of. Certainly not Java. Java is (IMO) practically defined by stagnation as a result of poor management by the companies that have owned it. And part of what I'm thinking here is getting away from the limitations imposed by Javascript. For example, Javascript lacks big integers, and is a dynamic language. My thought is that decoupling the HLL from the runtime would allow for faster evolution, because it's hypothetically easier to add new opcodes to a bytecode and VM than it is to make large shifts to a high-level language. Consider the whole dynamic thing in particular - .NET has a great VM with pretty good support for both static and dynamic languages. Java didn't, but again we aren't strictly required to repeat the mistakes of the past. And by just using "Javascript as the bytecode" we commit the reverse sin - that's a 'bytecode' with poor support for static languages.