-----BEGIN PGP SIGNED MESSAGE-----
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.
Regards
- --
Alex Russell
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFKRtGnz3jiQlnDlyMRAlHkAJ0ZT3c0PuUmjlKOdJWdrfS6FSfMwgCfa9A+
V4DPi75RD1U5WkkltL5imTU=
=7yy5
-----END PGP SIGNATURE-----
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
