Javascript bytecode

[deadalnix]

On Tuesday, 18 December 2012 at 21:30:04 UTC, Walter Bright wrote:
> D is open source. There is little implementation cost to doing 
> a compiler for it. It's a solved problem.
>

Let me emit some doubt about that.

First, D is difficult to compile because of the compile time 
features. DMD frontend is not the best piece of software I've 
seen on an extensibility point of view.

Plus, if D is open source in its license, it isn't in its way of 
doing things. When you drop functionality into master for reason 
the community isn't even aware of, you don't act like in an open 
source project. You'll find a huge gap between adopting a license 
and adopt the cultural switch that is required to benefit from 
open source.

Right now, it is painfully hard to implement a D compiler, for 
various reasons :
  - No language spec exists (and dmd, dlang.org and TDPL often 
contradict each others).
  - The language spec change constantly.
  - Sometime by surprise !
  - Many behavior now considered as standard are historical dmd 
quirks, that are hard to reproduce in any implementation not 
based on dmd.
  - Nothing can be anticipated because goals are not publics.
  - Sometime you'll find 2 specs (-property) for the same thing.
  - Many things are deprecated but it is pretty hard to know which 
one.
  - It in unknown how to resolve paradoxes created by compile time 
features.
  - I can go on and on.

Right now only dmd based front end are production quality, and 
almost no tooling exists around the language. You'll find very 
good reasons for that in the points listed above.

> A bytecode requires another spec to be written, and if you 
> think it's easy to make a conformant Java VM bytecode 
> interpreter, think again :-)
>

Nobody ever said that.

> Yes, it is trivial. The only thing that is lost are local 
> variable names and comments.

You'll find tools that compact your whole project, loosing in the 
process all names.