4 ms·

If you're right, and can land optional types and bignums soon, then Dart's semantics can become a subset of ECMAScript. At this point it's pretty easy to replac

by xxgreg 12y ago

If you're right, and can land optional types and bignums soon, then Dart's semantics can become a subset of ECMAScript. At this point it's pretty easy to replace the Dart language in the VM to support the ECMAScript syntax subset, and source code translate the core libraries over to ECMAScript. Then you have a fast VM which supports an easily optimisable subset of ECMAscript, and a large class library. This still seems like a good outcome to me. "any real-world usage data from it are nowhere" Ignoring available data from existing optionally typed VMs during the standardisation process doesn't seem like a smart idea. Anyway, I hope there is good discussion at TC39 about Nominal typing with implicit interfaces, vs Structural typing. I'm not really a fan of structural typing - I think the Dart team made the right call here. > Alan Kay was right, the best way to predict is to invent. You mean to invent something compatible with legacy technology and easily adopted ;)

BrendanEich 12y ago
> If you're right, and can land optional types and bignums soon, First, "soon" is incremental and staged, so it's not as though full optional types won't take till 2020 to be "landed" as in standardized and widely implemented. Second, the only way to get to that 2020 is by working in TC39 now, 2015, as SoundScript is. Not pulling a Dart in 2010, doing a different language and VM, making a disjoint Ecma standard, and then hoping to pull off a last minute rendezvous. > then Dart's semantics can become a subset of ECMAScript. They cannot, without incompatible changes. This doesn't fit your "big investment now for great tooling, easy migration later" thinking for Dart, and it's right out for JS. Problems go beyond bignums, but just bignums are enough. Dart can start a counter at 0 and ++ it past 2^53 without loss of precision. JS can't (you'd have to use bignum(0) or 0n). Something's got to give, and it looks likely to be infeasible to statically analyze and auto-fix all the code. > At this point it's pretty easy to replace the Dart language in the VM to support the ECMAScript syntax subset, and source code translate the core libraries over to ECMAScript. Then you have a fast VM which supports an easily optimisable subset of ECMAscript, and a large class library. This still seems like a good outcome to me. Except that this won't happen in 2020 thanks to Dart, because it forked hard early. Instead we will get to 2020 (maybe 2018) with SoundScript standardized, still incompatible with Dart, and no good outcome for Dart users who can't get dart2js to perform as well as DartVM. But in this scenario there's likely little market pressure on browsers to do the crazy amount of work to support multiple VMs. Good outcome? Worse, this is a narrow, self-interested point of view from Dart side. What about the JS side? Why should we have waited five years at least to get to SoundScript? How much sooner from 2010 or even 2015 could we get to the promised land if Dart weren't flying off toward Pluto? > "any real-world usage data from it are nowhere" > Ignoring available data from existing optionally typed VMs during the standardisation process doesn't seem like a smart idea. Cut the bad-faith arguing, please. It's not up to me to find Dart's "data" (where is it available, pray tell?) and try to separate all the confounding variables arising from Dart being a different VM and language. Sound/StrongScript in V8, OTOH, will give unconfounded data this year, in the context of JS and TC39. Who are you gonna bet on? Anyway, leave me out of it, try begging some Dart staffer for "data". > Anyway, I hope there is good discussion at TC39 about Nominal typing with implicit interfaces, vs Structural typing. I'm not really a fan of structural typing - I think the Dart team made the right call here. Did you read the StrongScript slides? Try http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirections.pdf http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirect... or better location. > > Alan Kay was right, the best way to predict is to invent. > You mean to invent something compatible with legacy technology and easily adopted ;) That's right, because of noted non-flamebait minor premise: JS cannot be replaced. Are you going to argue against this forthrightly? I thought not!
- 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 ago
    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 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.

by xxgreg 12y ago

BrendanEich 12y ago

> If you're right, and can land optional types and bignums soon, First, "soon" is incremental and staged, so it's not as though full optional types won't take till 2020 to be "landed" as in standardized and widely implemented. Second, the only way to get to that 2020 is by working in TC39 now, 2015, as SoundScript is. Not pulling a Dart in 2010, doing a different language and VM, making a disjoint Ecma standard, and then hoping to pull off a last minute rendezvous. > then Dart's semantics can become a subset of ECMAScript. They cannot, without incompatible changes. This doesn't fit your "big investment now for great tooling, easy migration later" thinking for Dart, and it's right out for JS. Problems go beyond bignums, but just bignums are enough. Dart can start a counter at 0 and ++ it past 2^53 without loss of precision. JS can't (you'd have to use bignum(0) or 0n). Something's got to give, and it looks likely to be infeasible to statically analyze and auto-fix all the code. > At this point it's pretty easy to replace the Dart language in the VM to support the ECMAScript syntax subset, and source code translate the core libraries over to ECMAScript. Then you have a fast VM which supports an easily optimisable subset of ECMAscript, and a large class library. This still seems like a good outcome to me. Except that this won't happen in 2020 thanks to Dart, because it forked hard early. Instead we will get to 2020 (maybe 2018) with SoundScript standardized, still incompatible with Dart, and no good outcome for Dart users who can't get dart2js to perform as well as DartVM. But in this scenario there's likely little market pressure on browsers to do the crazy amount of work to support multiple VMs. Good outcome? Worse, this is a narrow, self-interested point of view from Dart side. What about the JS side? Why should we have waited five years at least to get to SoundScript? How much sooner from 2010 or even 2015 could we get to the promised land if Dart weren't flying off toward Pluto? > "any real-world usage data from it are nowhere" > Ignoring available data from existing optionally typed VMs during the standardisation process doesn't seem like a smart idea. Cut the bad-faith arguing, please. It's not up to me to find Dart's "data" (where is it available, pray tell?) and try to separate all the confounding variables arising from Dart being a different VM and language. Sound/StrongScript in V8, OTOH, will give unconfounded data this year, in the context of JS and TC39. Who are you gonna bet on? Anyway, leave me out of it, try begging some Dart staffer for "data". > Anyway, I hope there is good discussion at TC39 about Nominal typing with implicit interfaces, vs Structural typing. I'm not really a fan of structural typing - I think the Dart team made the right call here. Did you read the StrongScript slides? Try http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirections.pdf http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirect... or better location. > > Alan Kay was right, the best way to predict is to invent. > You mean to invent something compatible with legacy technology and easily adopted ;) That's right, because of noted non-flamebait minor premise: JS cannot be replaced. Are you going to argue against this forthrightly? I thought not!

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 ago
  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 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.