I am always amused by the continuing demands for more
performance. The only real advantage of performance as a major
metric is that it is relatively easy to measure.
If performance is your number one goal, then the only languages
you should consider are assembler and machine language. :-)
On the other hand, if you like safety, security,
maintainability, understandability etc., then recognize that
these features have associated costs.
On 9/13/11 at 7:48, [email protected] (Brendan Eich) wrote:
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
* A big problem is predictability, it is a black art to get the best
performance out of contemporary JS VMs.
This is the big one in my book. Optimization faults happen. But can we iterate
till flat?
A set of rules a developer interested in performance can use
would be helpful. Particularly if they applied to more than one
implementation. :-)
* The massive complexity that comes with implementing all this affects
stability.
This one I'm less sympathetic to, since we won't get rid of
untyped JS up front. A sunk cost fallacy? If we could make a
"clean break" (ahem), sure. Otherwise this cost must be paid.
We could get better stability with simpler, less performant VMs.
Some users might prefer the increased stability and security
such a VM would offer.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | Privacy is dead, get over | Periwinkle
(408)356-8506 | it. | 16345
Englewood Ave
www.pwpconsult.com | - Scott McNealy | Los Gatos,
CA 95032
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
