alex at dojotoolkit.org
Sat Jun 27 19:12:55 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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-
slightlyoff at google.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
-----END PGP SIGNATURE-----
More information about the es-discuss