3 ms·

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create

by equark 15y ago

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?

BrendanEich 15y ago
JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode). These all add some cost in either runtime guards, static analysis burdens, or a mix. A new language could leave out most of these, but it would still want inheritance. Then the question would be: how useful is mutability along the inheritance chain, i.e. shadowing -- even if you remove 'delete'. Beyond this, a new language or a JS extension (this is what the Dash memo rules out as un-possible, without evidence) could allow pinning down the shape of objects, even to include machine types such as int32, etc. That would allow for big speedups on certain benchmarks.
- deleted 15y ago
  [deleted]
- equark 15y ago
  I hope Dart proves this out. Things like lack of machine types and operator overloading make Javascript unusable for the data analysis and statistical computing work I'm doing. While these may be feasible Javascript extensions, I can't see how that would come about in the <10 year time frame. And I doubt it would ever happen without some counter example VM. The typical response is that data analysis and statistical computing are server-side tasks. But that is not entirely true. Almost all the scientific applications I have worked on have major front-end needs where the web could help tremendously. On a broader note, one thing I don't quite understand is the complaint about lack of resources. The web browser is one of the most fundamental pieces of technology that exists today. They are also reasonably profitable. From my understanding Google gives Mozilla $60 million a year for the search bar. If browser vendors cannot dedicate new teams of 2-10 programmers on some feature -- like a Dart VM or NaCL clone -- I'm inclined to say the industry should consolidate. New VMs for Javascript are created by hobbyist coders all the time, as part time projects. Why is implementing a new VM and language so much work for Mozilla?

by equark 15y ago

BrendanEich 15y ago

JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode). These all add some cost in either runtime guards, static analysis burdens, or a mix. A new language could leave out most of these, but it would still want inheritance. Then the question would be: how useful is mutability along the inheritance chain, i.e. shadowing -- even if you remove 'delete'. Beyond this, a new language or a JS extension (this is what the Dash memo rules out as un-possible, without evidence) could allow pinning down the shape of objects, even to include machine types such as int32, etc. That would allow for big speedups on certain benchmarks.

deleted 15y ago
[deleted]
equark 15y ago
I hope Dart proves this out. Things like lack of machine types and operator overloading make Javascript unusable for the data analysis and statistical computing work I'm doing. While these may be feasible Javascript extensions, I can't see how that would come about in the <10 year time frame. And I doubt it would ever happen without some counter example VM. The typical response is that data analysis and statistical computing are server-side tasks. But that is not entirely true. Almost all the scientific applications I have worked on have major front-end needs where the web could help tremendously. On a broader note, one thing I don't quite understand is the complaint about lack of resources. The web browser is one of the most fundamental pieces of technology that exists today. They are also reasonably profitable. From my understanding Google gives Mozilla $60 million a year for the search bar. If browser vendors cannot dedicate new teams of 2-10 programmers on some feature -- like a Dart VM or NaCL clone -- I'm inclined to say the industry should consolidate. New VMs for Javascript are created by hobbyist coders all the time, as part time projects. Why is implementing a new VM and language so much work for Mozilla?