3 ms·
Ah. Interfaces are structural. Didn't notice that first time through. Thanks for the pointer. JS cannot be replaced in the short term. However you can implemen
by xxgreg 12y ago
Ah. Interfaces are structural. Didn't notice that first time through. Thanks for the pointer.
JS cannot be replaced in the short term. However you can implement a VM (or mode) which supports only a subset of JS with some of the legacy cruft removed. Strongscript is a step in this direction. (Side note - deprecate a few more features and you can start reusing some of the optimisations in the Dart VM.)
It is also possible to treat JS source as an AST serialization format an to display code differently when viewed by the developer. When language semantics are close to 1:1 this can work seamlessly (unlike of the big unintelligible balls of source required to work around ES5 semantic gaps).
And who knows, give it 10 years, and perhaps TC39 members will agree on a new language syntax that fits the existing "use strong" semantics. Note there is no need for expensive new VMs in this scenario, it is just a new parser generating AST nodes in the existing VM. This seems pretty obvious, I mean it's a bit of cruel joke to make developers use === for the next few decades. Surely this can be fixed some day.
Forgive my naivety about TC39 and standards, but I would have thought when standardising a new language feature that it makes sense to review similar features in other languages, and to perhaps reach out to implementers, for a presentation, or at least some email discussion. Seems prudent to learn from other's mistakes.
Btw. It is trivial to statically analyse Dart code, and even ignoring type annotations, decide whether a number literal is an integer or a double. And yes such automatic translation wouldn't be possible until changes like strongscript and bignums have landed in ES. But perhaps I misunderstand your point.
- BrendanEich 12y agoNope, your "Ignoring available data" weasel words, implying negligence by me or TC39 for not carrying Dart's water, were below-the-belt. No one is "ignoring available data". Dart's type system, in particular its covariant subtyping unsoundness, outraged Andreas Rossberg of the new V8 team. He expressed himself plainly about this on LtU the other year: http://lambda-the-ultimate.org/node/4377#comment-67586 http://lambda-the-ultimate.org/node/4377#comment-67586 Andreas and many others among us TC39ers are well acquainted with Dart. I think this intra-Google, anti-Dart outrage motivated SoundScript, in part. That doesn't mean the "data" is out there on some Dart public wiki to inform SoundScript's design in ways that programming language research and development do not already sufficiently inform it -- that we should just go get it, or we're slackers. I think you know this. Yes, all dynamic language VMs will look more alike in 10+ years. StrongScript or a closely related descendent of it in 5 still beats Dart, and I'm still right that this took too long by 5 years at least, precisely because of the bad politics and JS-can't-be-fixed-but-it-can-be-replaced fallacies of the Dash memo that pre-forked and diverged Dart too much, without JS uplift apart from SIMD. Are you done defending this sideshow as a productive experiment that helps the Web? Because so far, apart from John McCutchan's work, it has not helped. Maybe it will emerge a dark horse winner, but odds are against.
- xxgreg 12y agoI apologise for the "weasel words". But to be fair they were in response to this relatively dismissive comment: "Dart and any real-world usage data from it are nowhere, while StrongScript is "on" and should generate V8-based data this year." I'm watching with interest to see how Soundscript turns out. In the meantime, Dart and its tooling has helped me be productive. And I hope you and your colleagues at TC39 are able to bring the same feeling of productivity to ES. I'm not hugely excited about the casts required in Typescript (and I assume Soundscript) when interacting with the DOM. For example as a developer I don't find it helpful that the following is a static warning: var input : HtmlInputElement = document.querySelector('input'); A cast fixes the warning, but is pretty verbose and ugly: var input : HtmlInputElement = <HtmlInputElement> document.querySelector('input'); I believe this was one of the motivations behind the implicit downcasts in Dart. But I will give Soundscript a shot, and see if a sound type system helps me catch more bugs and be productive. I also wonder how much complexity variance will bring to generics in Soundscript. I believe they are invariant in the initial doc that I saw. Thanks for taking the time to share your views - I do honestly appreciate it. And I am very grateful that you got first class functions into JS1 - so that we've all had an ok language since the start. Definitely not accusing you of being a slacker. > I'm still right that this took too long by 5 years at least I think you overstate your case. But I've used enough of your valuable time already. It also sounds like you're now happy with the outcome, the Aarhus leadership sidelined, and new people on V8 with views more similar to your own. Go for it - get optional types shipped!
- BrendanEich 12y agoWe're overindented -- thanks for this comment, anyway. I'm not happy with anyone "sidelined", including Aarhus people, even if self-sidelined by too much funding, loathing of JS, and desire to work from a cleaner slate. This was far from optimal or necessary, even if you dig the tooling. Many Googlers agree with me. /be
- BrendanEich 12y agoA Google friend with Polish-American accent pronounces "the DOM" as "the Dumb", and I agree. Don't fret about usability of future DOM APIs in an evolution of SoundScript. I'm 100% sure they can be as sweet as Dart's Dumb, er, DOM. :-) /be