Javascript bytecode

Walter Bright newshound2 at digitalmars.com
Wed Dec 19 01:25:40 PST 2012


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.



More information about the Digitalmars-d mailing list