Comment by xxgreg | Hacker News Reader

Comment by xxgreg | Hacker News Reader

Parent Full thread

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.

Nope, 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

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.

I 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!

We'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

A 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

The way that people are using the DOM:

1) Large interdependent libraries that try to "fix" the DOM (and provide widgets, MVW, etc. 2) The common practice of loading scripts over external domains. This compromises privacy & security and is possible because of the same-origin policy.

The DOM is not idiot-proof. But the way that they are using it causes undue problems.

Isn't this problem inherent in the Soundscript type system, rather than a problem of the DOM? For example:

class Node { ... }

class FancyNode extends Node { ... }

function createNode() : Node => new FancyNode();

function doStuff(Node n) { ... }

doStuff(createNode()); // Static error - developer scratches his head - how do I fix this

doStuff(<FancyNode>createNode()); // There I fixed it. But at what cost to productivity.

Or perhaps (Not sure how Any<T> works - just guessing):

function doStuff2(Any<Node> n) { ... } // Developer - hey what's this Any<T> thing? More head scratching.

Is the extra complexity worth it, what benefits does it bring, and what are the productivity costs? Will soundness actually help runtime performance (Not proven). Will it make security harder? i.e. performance optimisations that rely on the sound type system mean that type spoofing can lead to vulnerabilities.

I keep on rambling - sorry - I find this stuff fascinating. Fun job you've got ;)

There's no type error in what you wrote, with or without the cast. But we're way over-indented now. Suggest trying ed-discuss for direct convo with Andreas R.

/be

Reply on news.ycombinator.com