extension modules

Alex Russell alex at dojotoolkit.org
Sat Jun 27 19:12:55 PDT 2009

Hash: SHA1

On Jun 23, 2009, at 11:11 AM, Brendan Eich wrote:

> On Jun 23, 2009, at 10:03 AM, kevin curtis wrote:
>> The requirement of security and speed don't always coincide! The  
>> subset/dialect idea is interesting.
> It's two-edged.
> Adding standard subsets leads to case-analysis explosion, a recipe  
> for bugs and reduction of interoperability.
> How subsets might evolve in future editions is another axis for  
> explosion of cases. Are subsets partially ordered in the same way  
> across future editions? Or should there be a total order? Can strict  
> mode get stricter over time?
>   ES5 ---------------> ES6 ...
>    ^                    ^
>    |                    |
>   ES5 strict <---?---> ES6 strict ...
> The arrowhead points to the superset. At some point we might have  
> ESn remove ancient cruft so the horizontal arrows might stop  
> pointing rightward.
> These are good questions and there may be compelling and simple  
> answers, but only for very few standard subsets. If you can't draw  
> the lattice, it's too complicated.
> Ideally, IMHO, the only standard subset will be strict mode.
>> let x:int = 0 // ES6 type annotation to indicate this will be  
>> turned into a c int at some point
>> ... etc
> We do not want int "for performance" if it auto-widens to double.  
> Adobe has experience here, and int as an annotation on local  
> variables (e.g. loop controls) is often a de-optimizer, yet users  
> over-use it "for speed".
> If as you propose ("C int", capital C meaning the C language, I take  
> it) we enable 32-bit machine int under a pragma, we'll have  
> wraparound bugs on the web. (People will copy and paste the pragma  
> to excess.)
> Because of the web-as-it-is, implementors have had to optimize JS as  
> it is used.
> But this has demonstrated, to me at least, that the important  
> language optimizations can be done well under the hood, without  
> hinting. IMHO this is a good use of human capital, compared to the  
> alternative of unleashing pragmas and machine types on the web  
> developer masses, where the pragmas and types add complexity and  
> often bite back.

I'd just like to double +1 this point. Getting things to be fast on  
the web came out of a group realization that web developers were  
leaning on JS since HTML wasn't evolving nearly fast enough to meet  
their needs. The performance of modern JS VM's is something us lowly  
DHTML hackers only dreamed of even a couple of years ago. JS got  
exercised for these tasks because it was both terse and flexible.  
Taking either of those properties away without a demonstrated need  
feels like a much larger loss to a JS programmer than I suspect it  
will to folks who are used to C++ or Java.

Getting some form of acceleration out of commonly-run scripts seems  
like a great goal, but I'm dubious that it should happen at the  
language level. I can more easily imagine something like HTML 5  
AppCache installation kicking off a pre-compile step that allows  
mostly-static script resources to elide away first-run compilation or  
in other ways apply more processor power to generating better/faster- 
starting code.


- --
Alex Russell
slightlyoff at google.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Version: GnuPG v1.4.2 (Darwin)


More information about the es-discuss mailing list