On 12/19/2012 1:10 AM, Rob T wrote:
Using the JS code as an example, you are stating that the JS source code itself could just as well be viewed as the "bytecode", and therefore given what I previously wrote concerning the "advantages", I could replace "bytecode" with "JS source code" and achieve the exact same result. Am I Correct?
Yes.
I thought that transforming source code into bytecode was an optimization technique intended to improve interpretation performance while preserving portability across architectures, i.e., the bytecode language was designed specifically to improve interpretation performance - but you say that the costs of performing the transformations from a high-level language into the optimized bytecode language far outweigh the advantages of leaving it as-is, i.e., whatever performance gains you get through the transformation is not significant enough to justify the costs of performing the transformation. Is my understanding of your POV correct?
Mostly. If you use bytecode, you have Yet Another Spec that has to be defined and conformed to. This has a lot of costs.
What I'm having trouble understanding is this: If the intention of something like the Java VM was to create a portable virtualized machine that could be used to execute any language, then would it not make sense to select a common bytecode language that was optimized for execution performance, rather than using another common language that was not specifically designed for that purpose?
Java as we know it evolved from a language that (as I recall) used bytecode to run on embedded systems of very low power. This use failed, and Java was re-imagined to be a network language that transmitted the bytecode over the internet. The rest was attempts to justify the investment in bytecode, or perhaps it simply never occurred to the Java engineers that the bytecode was redundant.
(Bytecode can make sense on 8 bit machines where the target machine simply has no capacity to run even a simple compiler. Such underpowered machines were obsolete by the time Java was developed, but the old ideas died hard.)
Do you have a theory or insight that can explain why a situation like the Java bytecode VM came to be and why it persists despite your suggestion that it is not required or of enough advantage to justify using it (may as well use Java source directly)?
Consider the US space shuttle design. It's probably the most wrong-headed engineering design ever, and it persisted because too many billions of dollars and careers were invested into it. Nobody could admit that it was an extremely inefficient and rather crazy design.
A couple NASA engineers have admitted to me privately that they knew this, but to keep their careers they kept their mouths shut.
