Javascript bytecode

[foobar]

On Wednesday, 19 December 2012 at 08:45:20 UTC, Walter Bright 
wrote:
> On 12/19/2012 12:19 AM, Max Samukha wrote:
>>> Evidently you've dismissed all of my posts in this thread on 
>>> that topic :-)
>> As you dismissed all points in favor of bytecode.
>
> And I gave detailed reasons why.
>
>> Such as it being a
>> standardized AST representation for multiple languages. CLI is 
>> all about that,
>> which is reflected in its name. LLVM is used almost 
>> exclusively for that purpose
>> (clang is great).
>
> My arguments were all based on the idea of distributing 
> "compiled" source code in bytecode format.
>
> The idea of using some common intermediate format to tie 
> together multiple front ends and multiple back ends is 
> something completely different.
>
> And, surprise (!), I've done that, too. The original C compiler 
> I wrote for many years was a multipass affair, that 
> communicated the data from one pass to the next via an 
> intermediate file. I was forced into such a system because DOS 
> just didn't have enough memory to combine the passes.
>
> I dumped it when more memory became available, as it was the 
> source of major slowdowns in the compilation process.
>
> Note that such a system need not be *bytecode* at all, it can 
> just hand the data structure off from one pass to the next. In 
> fact, an actual bytecode requires a serialization of the data 
> structures and then a reconstruction of them - rather pointless.
>
>
>> Not advocating bytecode here but you claiming it is completely 
>> useless is so
>> D-ish :).
>
> I'm not without experience doing everything bytecode is 
> allegedly good at.
>
> As for CLI, it is great for implementing C#. For other 
> languages, not so much. There turned out to be no way to 
> efficiently represent D slices in it, for example.

There other part of an intermediate representation which you 
ignored is attaching *multiple backends* which is important for 
portability and the web.
Applications could be written in safeD (a subset that is supposed 
to have no implementation defined or undefined behaviors) and 
compiled to such an intermediate representation (let's call it 
common-IR since you don't like "bytecode"). Now, each client 
platform has its own backend for our common-IR. We can have 
install-time compilation like in .NET or JIT as in Java or both, 
or maybe some other such method.
Having such format allows to add distribution to the system. The 
serialization and de-serialization is only pointless when done on 
the same machine.

Another usecase could be a compilation server - we can put only 
the front-end on client machines and do the optimizations and 
native code generation on the server. This can be used for 
example in a browser to allow D scripting. Think for instant 
about smart-phone browsers.

the dreaded "bytecode" helps to solve all those use cases.