4 ms·

tl;dr -- you took too many words spelling out what I already said: that Dart diverged too much and can only hope to rendezvous with ES2030. First, it can't wit

tl;dr -- you took too many words spelling out what I already said: that Dart diverged too much and can only hope to rendezvous with ES2030. First, it can't without careful separation of its incompatible breaks with JS, from whatever optional type system is standardizable in future JS. The two are intertwined in Dart right now. JS is not going to break compat or add opt-in version selection to runtime-incompatible modes. That died with ES4, buried by 1JS. Second, 2030 or even 2020 is way too far out, given the interest in TC39 right now from Google, Facebook, Microsoft, and other members. And because it took the long-odds bet, Dart is now clearly less likely than TypeScript => StrongScript to have any say on future JS optional types (AKA the revenge of ES4). You write "I also think it gives a lot of real world usage data helpful for getting optional types into ES. (You seem to disagree here.)" I'm not disagreeing just as a speculative opinion about 2020. I'm telling you that Dart has missed the optional types boat now, in TC39 -- the next meeting in less than two weeks. Dart and any real-world usage data from it are nowhere, while StrongScript is "on" and should generate V8-based data this year. On the laundry list of "optional types / completion / doc popups...": most of this has been done without Dart in full or even Dart's optional types, including in the Closure compiler. (See DoctorJS for early higher-order control flow analysis that could do completion without making programmers declare types all over.) Even the claim that a new VM is needed to do the complete laundry list is suspect at this point. Yeah, it's nice to have a clean slate, or one starting from StrongTalk's slate, as Dart did. But if only Google can afford it, it diverges incompatibly up front, and it can only partially re-converge far in the future, then it is very likely a "miss". Life is not just a series of random Homer Simpson events, with everything about possible futures a matter of opinion. People bet on futures profitably, beating fair coin tosses. Alan Kay was right, the best way to predict is to invent. So the smart money is not on Dart designing future optional types for JS. This could change but I doubt it, since Dart broke too much compatibility, unnecessarily for the purposes of making types optional. No one is disentangling and minimizing a proposal for ES7 or ES8 (2016 or 2017), while StrongScript is in pole position. This is much more like how standards evolution should work than the silly Dash memo's model.

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

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!