Javascript bytecode

[Rob T]

On Wednesday, 19 December 2012 at 07:22:45 UTC, Walter Bright 
wrote:
> On 12/18/2012 11:04 PM, Rob T wrote:
>> I'm not claiming to be an expert in this area either, however 
>> it seems obvious
>> that there are significant theoretical and practical 
>> advantages with using the
>> bytecode concept.
>
> Evidently you've dismissed all of my posts in this thread on 
> that topic :-)

I really am trying to understand your POV, but I'm having a 
difficult time with the point concerning performance.

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?

I will agree that the bytecode could be encoded as JS (or as 
another language) and used as a common base for interpretation or 
compilation to machine code. I can also agree that other 
languages can be "compiled" into the common "bytecode" language 
provided that it is versatile enough, so from that POV I will 
agree that you are correct.

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?

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?

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)?

--rt