4 ms·

I think your argument is clear - but I think you're also missing a point about another approach to evolving JS, and how development stacks such as Dart can fit

by xxgreg 12y ago

I think your argument is clear - but I think you're also missing a point about another approach to evolving JS, and how development stacks such as Dart can fit into this. Bignums - ok - you claim that bignums could have made it into ES6 if google had provided more support. I'll take your word for it, but you can probably understand my scepticism. I'm not religious about language either. I don't care much about syntax. What I really care about is being productive. IMHO the main things that help my productivity are: * optional types * completion * doc popups * development-time runtime type checking * good debugger * Few implicit conversions * Consistent core library Now you argue that google would have been better off building these language features and tooling on top of ECMAScript instead of creating the Dart stack. What would this alternative scenario actually look like - especially from the point of view of a developer? * It could be a mode in V8, or a fork of V8 (I'll call it "V8FutureMode"). V8FutureMode would be incompatible with other vendors JS VMs. Just as Dart is. * Each time ES standardises a new feature already in implemented in V8FutureMode, then all your existing code would need to be updated to match the ES spec. This regular churn is painful for developers. Now let's consider another scenario where google develops Dart, and ES20 arrives in 2020 with optional typing. * 2013-2020. Stable language no breaking changes. * In 2020 I can port my code over to ES20 (trivial as near 1:1 semantics, 99% automated). This scenario is better for me as a developer. It also insulates me from the risk that optional types don't make it into ES until 2030. I also think it gives a lot of real world usage data helpful for getting optional types into ES. (You seem to disagree here.) From the Dart team's perspective the Dart scenario is better too: * Can build a core library and tools on a stable language, rather than having to regularly deal with breaking changes. * Able to experiment with VM optimisations which are difficult to do in JS due to legacy compat. * Personal motivation - this is what the developers really want to work on. (Being told by your boss to drop your experimental project, and continue doing the same old thing isn't always a good management approach) I'm optimistic that over time experiments such as "use strong" will mean that the same optimisations implemented in the Dart VM will be able to be used in other JS VM's. Perhaps if a developer guarantees that all JS code is "use strong ES20", then it would be possible for a browser to even use a different VM behind the scenes (in Chrome perhaps even using the original Dart VM codebase, but with the language front-end changed to compatible with ES20). The future is uncertain and difficult to predict. There are multiple ways to evolve JS - you seem quite certain that incrementally fixing JS is the only approach. I think building a new programming stack, and simultaneously evolving JS in that direction with insights learnt from the new stack, is also a valid approach. I don't understand why you have been so hostile towards this.

BrendanEich 12y ago
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 ;)

by xxgreg 12y ago

BrendanEich 12y ago

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 ;)