Holding to as brief a reply as possible given short time to write it (apologies to Blaise Pascal):
* Python 1.3, stripped of most of its C extensions, may have been substantially better than JS1, I grant -- that was your digression and straw-man, not the point of the text to which you replied.
I do dispute that a forked-and-stripped Python 1.3, slowly evolved thereafter, would be materially better than what JS became. Just consider whitespace-based indentation vs. minification, for one issue.
* I'm very well acquainted with the sunk-cost fallacy. But that is not why JS endures.
JS endures because given the scale of the Web and the consequent backward-compatibility imperative for browsers, the switching cost is extremely high for web developers and browser hackers. The cost of adding a 2nd runtime faced by browser hackers is also high (but less high). Most important, the conserved evolutionary-kernel of JS is "good enough" (worse is better, look it up -- sorry about the warts but not sorry, we have to deal with the world as it is).
Therefore no browser (not even Chrome yet) has both the means and the motivation to invest lots of megabucks in engineering high-performance, multiple language runtime tenants sharing the DOM and the rest of the browser APIs.
Compile to JS sucks away the oxygen from any such boondoggle. There are multiple Python-to-JS compilers out there. With modern JS (both language and VM-level optimizations), you can get higher fidelity Python this way than you would have by forking and freezing Python 1.3.
* XHTML2 was revolution, not evolution. It proposed to replace HTML on the web, not even interoperating well with HTML via the DOM, before we founded the WHATWG and did HTML5. HTML was originally an SGML fork that, as it evolved, bent or violated lots of SGML rules in favor of flat vocabulary, ad-hoc error correction, implicit content models (I perpetrated implicit CDATA for <script>), and worse-is-better.
XHTML would yellow-screen-of-death if it didn't validate, and because IE loading the most popular MIME type would error-correct as HTML, even hard-core XML purists would commit errors to published content, unaware. This plus the better-is-better overhead and complexity of authoring XHTML (XML namespaces in particular) led to ~0 adoption.
* On me vs. Dart, as on your assertion that multiple runtime integration is much less complex than unstated Mozilla work, you have yet to cite sources. I'm bored by such cheap shots, so will wrap up here with a few thoughts about Dart and its opportunity costs. Feel free to have last words.
If you care to read my past HN comments, I railed against the Google "Dash" memo for being two-faced about "we <3 JS; we must REPLACE JS", about the latent and very large conflict of interest for Google as self-congratulatory standards bearer: investing in Dart at the expense of JS.
Indeed Google has probably sunk tens of millions into Dart with very little to show for it. Elsewhere here, you asked or assumed that Google uses Dart in its web properties. Does it? So far, I hear it does not, and I've asked Googlers. You should not assume.
UPDATE via twitter, thanks to @rightisleft -- some Google services use Dart now:
This means dart2js, which means Google should've already helped get bignums into ES6 :-|. END UPDATE LOL
Dart cost Google some V8 competitiveness, vs. other engines. The whole Aarhus team (except for moonlighters) switched to Dart; a new V8 team had to be recruited in Munich. You could say it's Google's choice on how to invest, and of course I agree, just considering business ethics.
But not for "Google the good" as standards bearer. There, the effect on JS standardization and real progress vs. the feared/hated mobile native stacks' languages (C++, ObjC on iOS) -- by such evolutions as asm.js/WebGL for games, and something like SoundScript for larger hand-coded apps -- was significantly delayed.
Big companies can work for and against the grain of the web. Elsewhere on this thread, a commenter replied to me about how ActiveX went against the grain (very true). Stuff like NaCl, Pepper, and Dart run the same wrong way, at first and even in the long run -- whether open source (open-washing a project dominated and controled by paid contributors is a hazard, even at Mozilla) or even de-jure standardized (Ecma is pay-to-play). The only way they'd get into other browsers is via market power of the 95% monopoly share kind that IE enjoyed around 2002.
Anyway, that's why I railed against the "Dash" memo. The delay in reconstituting the V8 team, and in coming up with something like SoundScript instead of Dart, is relevant to this current thread. If the topic of what's both practical to evolve from JS, and better for developers over against compile-to-JS approaches, is worth arguing about, then I'll argue that Google let the world down by doing Dart.
Evolution delayed, but not denied, still hurts. I'm glad to see the new V8 team proposing experiments like this one.
I occasionaly read the esdiscuss list, and from those discussions, I get a sense that it is incredibly difficult to evolve JS given the legacy compatibility constraints.
In my view having the Dart team trial new features in a new codebase without the legacy constraints allows them to move quickly, and get feedback about new features by shipping real code in real products. The results of this process can give good input back to the ECMAScript process. Perhaps this has already happened, I guess good examples would be SIMD, and the scoping rules around for of loops.
One of the most important improvements I see in Dart, is the focus on reducing start up time. i.e. snapshots and lazy evaluation of top level variable initialisers. They are currently claiming a 10x start up time when snapshots are used. This would be a huge benefit for mobile apps.
Is there any one investigating how you chould change or subset Javascript to allow for snapshotting? Snapshotting seems really beneficial for the web, especially for the mobile web vs native. Currently I only see the Dart team working on this.
Dart may prototype ideas that land in JS, but then why not help with bignums sooner (see http://code.google.com/p/dart/issues/detail?id=1533)? Time's a-wasting, Dart started at least in 2010 (first I heard of it was that spring).
JS compat constraints would affect anything like it at scale, see also HTML5 and version-as-anti-pattern-on-Web.
Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail.
Honestly, ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech. Again, Dart ain't gonna replace JS in the foreseeable future. We need progress on the Web we have, not a dream-Web we can't have.
It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors would have also implemented it already? I find this scenario unlikely - but you obviously have a better view of this than I do.
> Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail.
I guess you'd need to add some extra restrictions, such as no top level code outside of functions including variable initialisers, and no modification of prototype chains. This seems hard to do with JS as it is written today. Perhaps the "use strong" experiment will make this easier.
> ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech
This is your intuition and opinion. Some people disagree, and have chosen to put their effort into another approach. Maybe you're right. Maybe they're right. Personally I think it's better to try both approaches, and let benchmarks settle this. From the benchmarks I've seen, snapshots look very promising.
> Dart ain't gonna replace JS in the foreseeable future
Flamebait! It doesn't need to. It just needs to provide good development tooling for some developers who prefer using it than vanilla javascript.
from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum).
With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been:
Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years.
No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms.
This is not a difference of opinion, it's a matter of choice and funding.
Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years.
What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD:
John replied that he was going to look at JS SIMD next.
So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in.
The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009:
It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation.
Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains).
Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost.
There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.
> Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost.
Ok, let's say JS continues to evolve over the next 5-10 years, and by this time all browsers support integers, optional types, operator overloading, less implicit conversion, and mixins. By this point compiling Dart to JS is trivial, and the cross compiled code is also completely readible. So I can take my existing Dart project and compile it to ES11, clean up a few things by hand, and then continue developing in ES11. In the meantime I've had 5-10 years being very productive developing in Dart with good tool support. This seems like a win to me.
Having a VM is also incredibly beneficial for development and debugging. These points alone justify investment in Dart.
But there are more benefits. Providing a testing ground for VM engineers to try out new features without legacy compatibility constraints. They haven't really got started on performance yet, and they're already solidly ahead of V8. This can provide insights for TC39, to see what kind of performance/memory improvements are possible if changes are made to the language.
> Bignums
I'm aware of the bignums strawman, and I'm aware the page on the wiki dates to 2010. But I repeat: even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors (including MS and Apple) would have also implemented them already? I find this scenario unlikely. (But kudos to MS/A for implementing the new ES6 features. I'm glad to see JS evolving)
> [Snapshotting] could be added to JS if it could be done for Dart.
My understanding was that the V8 team actually implemented snapshotting and initially used it for loading their JS core library. They didn't think it was possible to use it for loading cached web code. Not because of the globals object, but because javascript code must be executed to build up classes, i.e. setting prototypes etc. Because execution and structure is interleaved, top level code and initialisors could perform side effects before the static program structure exists.
> there hasn't been much uplift over five years.
It looks like Dart is a longer term bet. It will be interesting to see what kind of an influence it has over the next decade or so. Especially given the recent talk around adding optional typing to JS. The Dart team are also currently experimenting with co-operative threading, growable stacks and concurrency primitives. https://github.com/dart-lang/fletch/wiki/Coroutines-and-Thre...
> My point about opportunity costs stands. We could have come a lot farther, faster.
I'm not convinced. I don't see how the development resourcing on the V8 development team could have sped up the ES6 standards process. The ES6 process includes getting consesus with Apple/Microsoft - this process isn't time constrained by V8 development resources.
Consider the opportunity cost if they chose not to develop Dart. Developers have to wait a lot longer to get modern tooling, with: completions, doc hovers, code navigation and static analysis. These really make a huge difference to developer productivity. All of the experience gained here can feed back into javascript tooling (assuming optional typing makes it into ES).
Also consider the individual developer's motivations. It's great that you are excited about working on JS and spidermonkey year after year. But what were the motivations of the developers at google? If the developers are passionate about the web like yourself, then they can continue to work with the V8 team. But if what excites them, is working on a state of the art dynamically typed VM, well then removing some of the legacy JS constraints allows them freedom to innovate. If their only choice had been to work on V8, they could well leave the company and work on another VM project somewhere else. So what would the cost have been if google management said no you can't do Dart?
> You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling" ... What's with the goalpost moving ... ?
The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.
I cite ES6 features now implemented by all the majors, and point to bignums as a proposal pre-dating Dart and pre-dating other ES6 proposals that got implemented. You assert against all evidence that, unlike all the other ES6 stuff implemented, a bignums proposal that was accepted for ES6 and prototyped in V8 would have been rejected by Apple and Microsoft. Makes total sense! :-|
Your goal-post shifting had the effect of letting Google off the hook for lack of uplift other than SIMD, so far. Great development tools and beneficial debugging! Lousy argument and defense against the lost opportunity for not only JS but dart2js, frankly.
A VM is an incredibly expensive investment, but Lars et al. were tired of JS and wanted what they wanted when they wanted it. (So does my three-year old.) Whether it makes economic sense in 40 years (the time-frame I've heard for when Dart finally takes over)? Who can say. Unfalsifiable.
That Dart has cost tens of millions of direct NRE at Google, and years of lost opportunities with V8 and TC39, is in the Basil-Fawlty-ian category of the bleeding obvious. There's no way to waffle around this point. You have to hold your breath for 40 years and hope.
> The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.
And I never said you did, so stop echoing my phrases. You called my "JS ain't gonna be replaced" flamebait, not goalpost moving. (I cited your obvious goalpost shifting, from "Dart helps uplift JS" to "at least we get great tools"; separate point!)
JS replacement wasn't ever a goal. I noted it can't be done, so it's not a goal. Nothing shifted. This fact is a painful truth that I cited as the minor premise of a syllogism:
Major: Web needs better programming language support than current JS, and soon. (The Dash memo was not wrong on this, although it overstated how mobile native stacks have better languages when the bigger issue is app/device/system APIs.)
Minor: JS cannot be replaced. (Anyone want to argue this?)
Therefore: JS needs to be improved soon. Easy to agree but harder to do, yet it is being done, e.g., ES6, SoundScript, plus over-the-top but informative tooling such as Flow and TypeScript.
We were arguing about the best way to improve JS. Since it can't be replaced, an entirely new second language and VM, especially without equivalent compile-to-JS semantics via JS uplift (bignums, more), has drawbacks:
* Super-expensive. (Other vendors won't do it without third bullet: market power abuse.)
* Leaves JS uplift to "later". (We've already seen this happen with bignums, but not with SIMD due to John McCutchan going extra miles.)
* Tempts market power abuse, a la ActiveX. (Not yet a real problem for the Web.)
In no way is there a goalpost to move about JS replacement. It's not in the cards. The only issue is how big a chunk of work and "time out" from improving JS should one take to test and bake new ideas.
To return to this HN thread, SoundScript is a quite-big chunk of work and time-out (much of this year, for some of the V8 team), yet it still looks aligned with the grain of the Web.
Dart without more JS uplift than the fine SIMD work is too big a chunk of work to produce much fruit for the Web soon.
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.
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.
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 ;)
> 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.
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:
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.
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. :-)
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.
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.
Technological improvements have increased the preponderance of crap on the web. Dart ain't gonna change that but it will give more centralized control to Google.
More technology means more corporations building crap. I should know, I've spent about three months of my 10+ year building things that were just slightly better than useless.
I'm looking forward to having integers in Javascript.
The dart2js numerics divergence isn't a problem in practice, as during testing/development the Dart VM is run with a flag which throws if an integer escapes the 2^53 safe range. And if an integer is overflowing to a double in production code then this is a bug anyway.
It would be nice if Javascript VM's could also provide a similar feature, at least until bignums land. But I guess this is difficult as there is no way to distinguish which numbers are intended to be integers and which are actually doubles.
after first asking someone to cite such a problem.
AFAICT the "isn't a problem in practice" happy-talk is all coming from Dart insiders. Does this shoe fit?
Anyway, it's a real Dart bug that drives potential users away. And why is JS bignum support -- which Google for-sure could have championed in Ecma TC39 and prototype-implemented in V8 -- just an "It would be nice" thing?
(It is not difficult to support suffixes for new value types, e.g. 0m for decimal and 0n or better for bignum. This is on the ES7 agenda. For more on range analysis and other/better optimization options, see https://news.ycombinator.com/item?id=6950475.)
Trusting checked-mode test coverage is bold in light of this bug, where bold might be "stupid" or "you're fired". As I wrote once in this thread already, Murphy was an optimist.
I agree this needs to be fixed in JS. And I have been following the ES strawmen/proposals. Not sure if I like suffixes. The approach in Dart seems to work well too.
In JS the overflow is often silent and is easy to miss. Since the DartVM can throw an exception on overflow this makes it easier to catch. So the Dart toolchain is an improvement, but also not ideal.
Where correctness is important there are also 32/64bit and bignum libraries which can be compiled to js but are slow.
* Python 1.3, stripped of most of its C extensions, may have been substantially better than JS1, I grant -- that was your digression and straw-man, not the point of the text to which you replied.
I do dispute that a forked-and-stripped Python 1.3, slowly evolved thereafter, would be materially better than what JS became. Just consider whitespace-based indentation vs. minification, for one issue.
* I'm very well acquainted with the sunk-cost fallacy. But that is not why JS endures.
JS endures because given the scale of the Web and the consequent backward-compatibility imperative for browsers, the switching cost is extremely high for web developers and browser hackers. The cost of adding a 2nd runtime faced by browser hackers is also high (but less high). Most important, the conserved evolutionary-kernel of JS is "good enough" (worse is better, look it up -- sorry about the warts but not sorry, we have to deal with the world as it is).
Therefore no browser (not even Chrome yet) has both the means and the motivation to invest lots of megabucks in engineering high-performance, multiple language runtime tenants sharing the DOM and the rest of the browser APIs.
Compile to JS sucks away the oxygen from any such boondoggle. There are multiple Python-to-JS compilers out there. With modern JS (both language and VM-level optimizations), you can get higher fidelity Python this way than you would have by forking and freezing Python 1.3.
* XHTML2 was revolution, not evolution. It proposed to replace HTML on the web, not even interoperating well with HTML via the DOM, before we founded the WHATWG and did HTML5. HTML was originally an SGML fork that, as it evolved, bent or violated lots of SGML rules in favor of flat vocabulary, ad-hoc error correction, implicit content models (I perpetrated implicit CDATA for <script>), and worse-is-better.
XHTML would yellow-screen-of-death if it didn't validate, and because IE loading the most popular MIME type would error-correct as HTML, even hard-core XML purists would commit errors to published content, unaware. This plus the better-is-better overhead and complexity of authoring XHTML (XML namespaces in particular) led to ~0 adoption.
* On me vs. Dart, as on your assertion that multiple runtime integration is much less complex than unstated Mozilla work, you have yet to cite sources. I'm bored by such cheap shots, so will wrap up here with a few thoughts about Dart and its opportunity costs. Feel free to have last words.
If you care to read my past HN comments, I railed against the Google "Dash" memo for being two-faced about "we <3 JS; we must REPLACE JS", about the latent and very large conflict of interest for Google as self-congratulatory standards bearer: investing in Dart at the expense of JS.
Indeed Google has probably sunk tens of millions into Dart with very little to show for it. Elsewhere here, you asked or assumed that Google uses Dart in its web properties. Does it? So far, I hear it does not, and I've asked Googlers. You should not assume.
UPDATE via twitter, thanks to @rightisleft -- some Google services use Dart now:
https://www.dartlang.org/community/who-uses-dart.html
This means dart2js, which means Google should've already helped get bignums into ES6 :-|. END UPDATE LOL
Dart cost Google some V8 competitiveness, vs. other engines. The whole Aarhus team (except for moonlighters) switched to Dart; a new V8 team had to be recruited in Munich. You could say it's Google's choice on how to invest, and of course I agree, just considering business ethics.
But not for "Google the good" as standards bearer. There, the effect on JS standardization and real progress vs. the feared/hated mobile native stacks' languages (C++, ObjC on iOS) -- by such evolutions as asm.js/WebGL for games, and something like SoundScript for larger hand-coded apps -- was significantly delayed.
Big companies can work for and against the grain of the web. Elsewhere on this thread, a commenter replied to me about how ActiveX went against the grain (very true). Stuff like NaCl, Pepper, and Dart run the same wrong way, at first and even in the long run -- whether open source (open-washing a project dominated and controled by paid contributors is a hazard, even at Mozilla) or even de-jure standardized (Ecma is pay-to-play). The only way they'd get into other browsers is via market power of the 95% monopoly share kind that IE enjoyed around 2002.
Anyway, that's why I railed against the "Dash" memo. The delay in reconstituting the V8 team, and in coming up with something like SoundScript instead of Dart, is relevant to this current thread. If the topic of what's both practical to evolve from JS, and better for developers over against compile-to-JS approaches, is worth arguing about, then I'll argue that Google let the world down by doing Dart.
Evolution delayed, but not denied, still hurts. I'm glad to see the new V8 team proposing experiments like this one.