Improving ECMAScript as a compilation target

Brendan Eich brendan at mozilla.com
Thu Feb 12 22:16:30 PST 2009


On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:

> Not at all and it is unfortunate it came across that way. It is at the
> whole chain of events which is long: "for the ECMAScript committee to
> standardize methodMissing, for browsers to implement it and for old
> browsers to disappear".

Standardizing a target bytecode or even AST encoding would take no  
less time, almost certainly more.

We should talk about methodMissing for Harmony.

The only consolation today, with renewed browser competition and self- 
updating browsers and OSes, is that it ought not take as long to see  
old user agent share drop as it did back in the bad old days.


>>> Is it inevitable that browser makers and/or the ECMAScript standard
>>> group will add features to ECMAScript specifically to make it a  
>>> better
>>> compilation target or expose actual byte code? By making ECMAScript
>>> engines faster, browser makers have already started. Should the  
>>> effort
>>> to make the browser a better compilation target be encouraged and
>>> expedited so the long drawn out "eventually" can come sooner?
>>
>> Why do you assume something not in evidence? Who says "eventually" or
>> "inevitabl[y]" there will be standard bytecode? Even if you end up
>> accurately predicting some future event, doing so prematurely based  
>> on a
>> hunch does not help us now in any way. Projecting enthusiastically  
>> about
>> hypothetical outcomes does not accelerate the process of developing a
>> suitable common language for hand-coders and code-generators.
>
> I didn't make predictions. I asked questions on purpose.

Sure, but your questions were loaded :-P.


> If a "common language for hand-coders and code-generators" is
> desirable, isn't it necessary to consider the code-generator part?

I didn't agree that such a desert-topping/floor-wax was desirable. I  
did suggest that implementations will optimize for workload offered by  
the web, including the code generator part of it, better and sooner  
(incrementally) compared to the standards process. And without bytecode!


> That was really the question of my whole post: should we be
> considering the code-generation part perhaps more than we are.

I still say no, for reasons given. I don't think the tail (committee)  
is wagging the dog (web content authoring by hand) here. If code  
generators take over along with Skynet, we can change focus. But the  
parts closer to the dog's brain (browser engines; dog meat :-P) will  
precede the committee and inform it.

/be


More information about the Es-discuss mailing list