4 ms·

> Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-langu

by xxgreg 12y ago

> Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. Ok, let's say JS continues to evolve over the next 5-10 years, and by this time all browsers support integers, optional types, operator overloading, less implicit conversion, and mixins. By this point compiling Dart to JS is trivial, and the cross compiled code is also completely readible. So I can take my existing Dart project and compile it to ES11, clean up a few things by hand, and then continue developing in ES11. In the meantime I've had 5-10 years being very productive developing in Dart with good tool support. This seems like a win to me. Having a VM is also incredibly beneficial for development and debugging. These points alone justify investment in Dart. But there are more benefits. Providing a testing ground for VM engineers to try out new features without legacy compatibility constraints. They haven't really got started on performance yet, and they're already solidly ahead of V8. This can provide insights for TC39, to see what kind of performance/memory improvements are possible if changes are made to the language. > Bignums I'm aware of the bignums strawman, and I'm aware the page on the wiki dates to 2010. But I repeat: even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors (including MS and Apple) would have also implemented them already? I find this scenario unlikely. (But kudos to MS/A for implementing the new ES6 features. I'm glad to see JS evolving) > [Snapshotting] could be added to JS if it could be done for Dart. My understanding was that the V8 team actually implemented snapshotting and initially used it for loading their JS core library. They didn't think it was possible to use it for loading cached web code. Not because of the globals object, but because javascript code must be executed to build up classes, i.e. setting prototypes etc. Because execution and structure is interleaved, top level code and initialisors could perform side effects before the static program structure exists. > there hasn't been much uplift over five years. It looks like Dart is a longer term bet. It will be interesting to see what kind of an influence it has over the next decade or so. Especially given the recent talk around adding optional typing to JS. The Dart team are also currently experimenting with co-operative threading, growable stacks and concurrency primitives. https://github.com/dart-lang/fletch/wiki/Coroutines-and-Threads https://github.com/dart-lang/fletch/wiki/Coroutines-and-Thre... > My point about opportunity costs stands. We could have come a lot farther, faster. I'm not convinced. I don't see how the development resourcing on the V8 development team could have sped up the ES6 standards process. The ES6 process includes getting consesus with Apple/Microsoft - this process isn't time constrained by V8 development resources. Consider the opportunity cost if they chose not to develop Dart. Developers have to wait a lot longer to get modern tooling, with: completions, doc hovers, code navigation and static analysis. These really make a huge difference to developer productivity. All of the experience gained here can feed back into javascript tooling (assuming optional typing makes it into ES). Also consider the individual developer's motivations. It's great that you are excited about working on JS and spidermonkey year after year. But what were the motivations of the developers at google? If the developers are passionate about the web like yourself, then they can continue to work with the V8 team. But if what excites them, is working on a state of the art dynamically typed VM, well then removing some of the legacy JS constraints allows them freedom to innovate. If their only choice had been to work on V8, they could well leave the company and work on another VM project somewhere else. So what would the cost have been if google management said no you can't do Dart? > You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling" ... What's with the goalpost moving ... ? The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.

BrendanEich 12y ago
This is going in circles. I cite ES6 features now implemented by all the majors, and point to bignums as a proposal pre-dating Dart and pre-dating other ES6 proposals that got implemented. You assert against all evidence that, unlike all the other ES6 stuff implemented, a bignums proposal that was accepted for ES6 and prototyped in V8 would have been rejected by Apple and Microsoft. Makes total sense! :-| Your goal-post shifting had the effect of letting Google off the hook for lack of uplift other than SIMD, so far. Great development tools and beneficial debugging! Lousy argument and defense against the lost opportunity for not only JS but dart2js, frankly. A VM is an incredibly expensive investment, but Lars et al. were tired of JS and wanted what they wanted when they wanted it. (So does my three-year old.) Whether it makes economic sense in 40 years (the time-frame I've heard for when Dart finally takes over)? Who can say. Unfalsifiable. That Dart has cost tens of millions of direct NRE at Google, and years of lost opportunities with V8 and TC39, is in the Basil-Fawlty-ian category of the bleeding obvious. There's no way to waffle around this point. You have to hold your breath for 40 years and hope.
BrendanEich 12y ago
> The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript. And I never said you did, so stop echoing my phrases. You called my "JS ain't gonna be replaced" flamebait, not goalpost moving. (I cited your obvious goalpost shifting, from "Dart helps uplift JS" to "at least we get great tools"; separate point!) JS replacement wasn't ever a goal. I noted it can't be done, so it's not a goal. Nothing shifted. This fact is a painful truth that I cited as the minor premise of a syllogism: Major: Web needs better programming language support than current JS, and soon. (The Dash memo was not wrong on this, although it overstated how mobile native stacks have better languages when the bigger issue is app/device/system APIs.) Minor: JS cannot be replaced. (Anyone want to argue this?) Therefore: JS needs to be improved soon. Easy to agree but harder to do, yet it is being done, e.g., ES6, SoundScript, plus over-the-top but informative tooling such as Flow and TypeScript. We were arguing about the best way to improve JS. Since it can't be replaced, an entirely new second language and VM, especially without equivalent compile-to-JS semantics via JS uplift (bignums, more), has drawbacks: * Super-expensive. (Other vendors won't do it without third bullet: market power abuse.) * Leaves JS uplift to "later". (We've already seen this happen with bignums, but not with SIMD due to John McCutchan going extra miles.) * Tempts market power abuse, a la ActiveX. (Not yet a real problem for the Web.) In no way is there a goalpost to move about JS replacement. It's not in the cards. The only issue is how big a chunk of work and "time out" from improving JS should one take to test and bake new ideas. To return to this HN thread, SoundScript is a quite-big chunk of work and time-out (much of this year, for some of the V8 team), yet it still looks aligned with the grain of the Web. Dart without more JS uplift than the fine SIMD work is too big a chunk of work to produce much fruit for the Web soon. Clear enough?

by xxgreg 12y ago

BrendanEich 12y ago

This is going in circles. I cite ES6 features now implemented by all the majors, and point to bignums as a proposal pre-dating Dart and pre-dating other ES6 proposals that got implemented. You assert against all evidence that, unlike all the other ES6 stuff implemented, a bignums proposal that was accepted for ES6 and prototyped in V8 would have been rejected by Apple and Microsoft. Makes total sense! :-| Your goal-post shifting had the effect of letting Google off the hook for lack of uplift other than SIMD, so far. Great development tools and beneficial debugging! Lousy argument and defense against the lost opportunity for not only JS but dart2js, frankly. A VM is an incredibly expensive investment, but Lars et al. were tired of JS and wanted what they wanted when they wanted it. (So does my three-year old.) Whether it makes economic sense in 40 years (the time-frame I've heard for when Dart finally takes over)? Who can say. Unfalsifiable. That Dart has cost tens of millions of direct NRE at Google, and years of lost opportunities with V8 and TC39, is in the Basil-Fawlty-ian category of the bleeding obvious. There's no way to waffle around this point. You have to hold your breath for 40 years and hope.

BrendanEich 12y ago

> The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript. And I never said you did, so stop echoing my phrases. You called my "JS ain't gonna be replaced" flamebait, not goalpost moving. (I cited your obvious goalpost shifting, from "Dart helps uplift JS" to "at least we get great tools"; separate point!) JS replacement wasn't ever a goal. I noted it can't be done, so it's not a goal. Nothing shifted. This fact is a painful truth that I cited as the minor premise of a syllogism: Major: Web needs better programming language support than current JS, and soon. (The Dash memo was not wrong on this, although it overstated how mobile native stacks have better languages when the bigger issue is app/device/system APIs.) Minor: JS cannot be replaced. (Anyone want to argue this?) Therefore: JS needs to be improved soon. Easy to agree but harder to do, yet it is being done, e.g., ES6, SoundScript, plus over-the-top but informative tooling such as Flow and TypeScript. We were arguing about the best way to improve JS. Since it can't be replaced, an entirely new second language and VM, especially without equivalent compile-to-JS semantics via JS uplift (bignums, more), has drawbacks: * Super-expensive. (Other vendors won't do it without third bullet: market power abuse.) * Leaves JS uplift to "later". (We've already seen this happen with bignums, but not with SIMD due to John McCutchan going extra miles.) * Tempts market power abuse, a la ActiveX. (Not yet a real problem for the Web.) In no way is there a goalpost to move about JS replacement. It's not in the cards. The only issue is how big a chunk of work and "time out" from improving JS should one take to test and bake new ideas. To return to this HN thread, SoundScript is a quite-big chunk of work and time-out (much of this year, for some of the V8 team), yet it still looks aligned with the grain of the Web. Dart without more JS uplift than the fine SIMD work is too big a chunk of work to produce much fruit for the Web soon. Clear enough?