On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
On 12/18/2012 10:29 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright
wrote:
Javascript proves that bytecode is not required for "write
once, run
everywhere", which was one of the pitches for bytecode.
What is required for w.o.r.e. is a specification for the
source code that
precludes undefined and implementation defined behavior.
Yes, bytecode isn't strictly required, but it's certainly
desirable. Bytecode is
much easier to interpret, much easier to compile to, and more
compact.
Bytecode would have added nothing to js but complexity.
I think you're seriously overestimating the cost of compilation.
When I say "easier", I'm talking about implementation cost.
Consider how easy it is to write a conforming Java byte code
interpreter compared to a conforming Java interpreter/compiler.
Parsing and semantic analysis are much easier to get wrong than a
byte code spec. At the bytecode level, you don't need to worry
about function overloading, symbol tables, variable scoping, type
inference, forward references etc. etc. All those things are
intentional complexities meant to make life easier for the
programmer, not the computer. A bytecode doesn't need them.
The downside of bytecode is loss of high-level meaning... but
that depends on
the bytecode. There's nothing stopping the bytecode from being
a serialised AST
(actually, that would be ideal).
As I pointed out to Andrei, Java bytecode *is* a serialized AST.
It's not a lossless serialisation -- especially not after
optimisation. For example, it's non-trivial to reconstruct the
AST of a for loop from optimised bytecode (or even regular
bytecode).
