12 ms·

Good for lulz, but this is really uninformed, if not made up from whole cloth. The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out, Jo

Good for lulz, but this is really uninformed, if not made up from whole cloth. The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out, John did the Dart work and then worked on https://github.com/johnmccutchan/ecmascript_simd; https://github.com/johnmccutchan/ecmascript_simd; I had some small helpful role to do with the project involving Mozilla and Intel, too) and the courage and validation -- not the idea, which pre-dates Dart -- of giving the for (let...) loop a binding per iteration in ES6 as in Dart, there has been no influence or help from Dart. Modules in ES6 have nothing to do with Dart, and the work started in 2010, well before Dart ("Dash") leaked. Classes too pre-date Dart, in some ways they go back to JS2/ES4 of the 1999-2003 era, and ES4 of the 2006-8 era. CoffeeScript owes a lot to Ruby and Python, of course, and I did design-champion fat arrow functions into ES6, inspired in part by CoffeeScript. ES6's for-of loop is responding to the same gravity-well as CoffeeScript's for-of, but it differs in substantial aspects. And so on. Languages influence one another -- news at 11 -- but Dart did very little intentional uplift work for JS. SIMD is the big and very good exception to this norm. Better late than never, I say. Now is a good time to help get value objects including bignums into ES7. https://code.google.com/p/dart/issues/detail?id=1533 https://code.google.com/p/dart/issues/detail?id=1533

bhouston 12y ago
> Good for lulz, but this is really uninformed, if not made up from whole cloth. To be clear, I didn't say that Dart or CoffeeScript associated people actively meant to be a guide for JavaScript (I'm pretty sure that having CoffeeScript and Dart effectively subsumed into JavaScript wasn't the goal), but the fact that these languages existed and has neat features did served as a guide for evolution of JavaScript. Thus I am making the case of much weaker case of languages influencing each other, rather than a stronger case. And there is massive influence going on here, whether intentional or not -- the speed at which features of Dart and CoffeeScript being pulled into JS is very rapid. I think your comments actually bare this out -- Dart people helping with SIMD, and you being inspired by CoffeeScript.
- BrendanEich 12y ago
  You wrote "influenced a lot of JavaScript standards people." Please name two. You wrote "The same is actually happening to the unique features of Dart such as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up work by John McCutchan, not "Dart people" plural -- there you go again), and nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript, Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no relation to Dart modules/packages. Really, "exaggeration" doesn't being to capture the false overreach of your first comment, and walking back from it to vague "everything's influencing JS" isn't helping. Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team; replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have bignums and other things that would materially aid correctness and performance of dart2js, which is now the only way forward for Dart in browsers. I hate playing Cassandra, but the good news is that Troy didn't fall: JS prevailed, at some unnecessary cost, and as predicted. See https://news.ycombinator.com/item?id=2982949 https://news.ycombinator.com/item?id=2982949 et seq.
  - michaelwww 12y ago
    John McCutchan caught my attention early on and my hat goes off to him. He brought a unique perspective to advancing performance. I went from Dart to TypeScript to pure JavaScript for a variety of reasons, and I must say productivity in Dart is higher, sometimes much higher. However the Dart2js output and interface makes it less attractive despite higher productivity. I took from the announcement that Google will focus on fixing that, which is encouraging. It's really the only way forward for Dart, since no one else, and now Chrome, is going to include the VM.
    - munificent 12y ago
      > I took from the announcement that Google will focus on fixing that, which is encouraging. That's exactly right. We have a bunch of people working feverishly on more human-friendly JS output: https://github.com/dart-lang/dev_compiler https://github.com/dart-lang/dev_compiler
  - 12y ago
tosh 12y ago
Looking fwd to see bignum support in ES7 fingerscrossed
- coldtea 12y ago
  Doing astronomy work in JS?
  - tkubacki 12y ago
    Without bignum it's hard to implement Decimal
  - bhouston 12y ago
    Very useful for spreadsheets and other financial calculations as well I believe, as well as some forms of custom Crypto.
    - BrendanEich 12y ago
      Definitely (and I'm happy to write a friendlier comment reply, believe me!). Bignums are good, in Dart as in other languages. On the agenda for "Harmony-era" ECMAScript, going back to 2009: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums More recent work generalizes value types into an extension mechanism for JS, so you can have built-in and user-defined numeric types with operators and literals.
    - coldtea 12y ago
      Aren't decimals better suited for financial applications? That's what I've used in the past in Java land (BigDecimal). Or are bignums and decimals the same thing? (not sure).
      - dragonwriter 12y ago
        Bignums are closely related to arbitrary precision decimals (aka BigDecimals; "decimal" without more is somewhat ambiguous since sometimes those are fixed size or decimal floating point.) Most financial applications deal with currencies each of which had a smallest indivisible unit in the application, which makes bignums most appropriate. But bigdecimals (or even arbitrary precision rationals) may be preferred in certain financial applications.

bhouston 12y ago

> Good for lulz, but this is really uninformed, if not made up from whole cloth. To be clear, I didn't say that Dart or CoffeeScript associated people actively meant to be a guide for JavaScript (I'm pretty sure that having CoffeeScript and Dart effectively subsumed into JavaScript wasn't the goal), but the fact that these languages existed and has neat features did served as a guide for evolution of JavaScript. Thus I am making the case of much weaker case of languages influencing each other, rather than a stronger case. And there is massive influence going on here, whether intentional or not -- the speed at which features of Dart and CoffeeScript being pulled into JS is very rapid. I think your comments actually bare this out -- Dart people helping with SIMD, and you being inspired by CoffeeScript.

BrendanEich 12y ago
You wrote "influenced a lot of JavaScript standards people." Please name two. You wrote "The same is actually happening to the unique features of Dart such as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up work by John McCutchan, not "Dart people" plural -- there you go again), and nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript, Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no relation to Dart modules/packages. Really, "exaggeration" doesn't being to capture the false overreach of your first comment, and walking back from it to vague "everything's influencing JS" isn't helping. Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team; replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have bignums and other things that would materially aid correctness and performance of dart2js, which is now the only way forward for Dart in browsers. I hate playing Cassandra, but the good news is that Troy didn't fall: JS prevailed, at some unnecessary cost, and as predicted. See https://news.ycombinator.com/item?id=2982949 https://news.ycombinator.com/item?id=2982949 et seq.
- michaelwww 12y ago
  John McCutchan caught my attention early on and my hat goes off to him. He brought a unique perspective to advancing performance. I went from Dart to TypeScript to pure JavaScript for a variety of reasons, and I must say productivity in Dart is higher, sometimes much higher. However the Dart2js output and interface makes it less attractive despite higher productivity. I took from the announcement that Google will focus on fixing that, which is encouraging. It's really the only way forward for Dart, since no one else, and now Chrome, is going to include the VM.
  - munificent 12y ago
    > I took from the announcement that Google will focus on fixing that, which is encouraging. That's exactly right. We have a bunch of people working feverishly on more human-friendly JS output: https://github.com/dart-lang/dev_compiler https://github.com/dart-lang/dev_compiler
- 12y ago

tosh 12y ago

Looking fwd to see bignum support in ES7 fingerscrossed

coldtea 12y ago
Doing astronomy work in JS?
- tkubacki 12y ago
  Without bignum it's hard to implement Decimal
- bhouston 12y ago
  Very useful for spreadsheets and other financial calculations as well I believe, as well as some forms of custom Crypto.
  - BrendanEich 12y ago
    Definitely (and I'm happy to write a friendlier comment reply, believe me!). Bignums are good, in Dart as in other languages. On the agenda for "Harmony-era" ECMAScript, going back to 2009: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums More recent work generalizes value types into an extension mechanism for JS, so you can have built-in and user-defined numeric types with operators and literals.
  - coldtea 12y ago
    Aren't decimals better suited for financial applications? That's what I've used in the past in Java land (BigDecimal). Or are bignums and decimals the same thing? (not sure).
    - dragonwriter 12y ago
      Bignums are closely related to arbitrary precision decimals (aka BigDecimals; "decimal" without more is somewhat ambiguous since sometimes those are fixed size or decimal floating point.) Most financial applications deal with currencies each of which had a smallest indivisible unit in the application, which makes bignums most appropriate. But bigdecimals (or even arbitrary precision rationals) may be preferred in certain financial applications.