3 ms·

Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that ex

Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that exceeds the integral domain of double is hard. Murphy says there will be bugs in other browsers when one's app tests "work in Chrome". For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it. The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome. Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to. /be

spankalee 13y ago
You must realize how different the situations are between Java BigIntegers and Dart integers.
- BrendanEich 13y ago
  Please, inform me, if you are not trolling on the cheap. https://www.dartlang.org/articles/numeric-computation/ https://www.dartlang.org/articles/numeric-computation/ http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html http://docs.oracle.com/javase/7/docs/api/java/math/BigIntege... Both arbitrary precision immutable integer types. If some corner case differs, my point stands. Google has more than enough engineers on Dart to do the work of writing a bignum library in JS, if they can't find one to use that someone already wrote. /be
  - spankalee 13y ago
    I'm definitely not trolling. I truly thought you would understand the basic difference. Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53 Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int domain, and when dealing with BigIntegers you're always in the BigInteger domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned. In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints. Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.
    - pcwalton 13y ago
      > dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases. Couldn't you just have changed Dart to fix the semantics? This is a big issue (no pun intended) that essentially means that dart2js is broken. I predict that, absent some solution to this issue, if Dart takes off, there will be sites that break in non-Chrome browsers when (for example) 64 bit hashing algorithms are involved due to authors only testing in Chrome and not testing the dart2js version.
    - BrendanEich 13y ago
      "I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs. Again, this is extremely old hat to the Dart/V8 folks. See, e.g. http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-... In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See http://rfrn.org/~shu/drafts/ti.pdf‎ http://rfrn.org/~shu/drafts/ti.pdf‎ This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics). Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton: https://github.com/pcwalton/doctorjsmm/ https://github.com/pcwalton/doctorjsmm/ Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing. Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier. http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39? /be

spankalee 13y ago

You must realize how different the situations are between Java BigIntegers and Dart integers.

BrendanEich 13y ago
Please, inform me, if you are not trolling on the cheap. https://www.dartlang.org/articles/numeric-computation/ https://www.dartlang.org/articles/numeric-computation/ http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html http://docs.oracle.com/javase/7/docs/api/java/math/BigIntege... Both arbitrary precision immutable integer types. If some corner case differs, my point stands. Google has more than enough engineers on Dart to do the work of writing a bignum library in JS, if they can't find one to use that someone already wrote. /be
- spankalee 13y ago
  I'm definitely not trolling. I truly thought you would understand the basic difference. Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53 Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int domain, and when dealing with BigIntegers you're always in the BigInteger domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned. In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints. Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.
  - pcwalton 13y ago
    > dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases. Couldn't you just have changed Dart to fix the semantics? This is a big issue (no pun intended) that essentially means that dart2js is broken. I predict that, absent some solution to this issue, if Dart takes off, there will be sites that break in non-Chrome browsers when (for example) 64 bit hashing algorithms are involved due to authors only testing in Chrome and not testing the dart2js version.
  - BrendanEich 13y ago
    "I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs. Again, this is extremely old hat to the Dart/V8 folks. See, e.g. http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-... In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See http://rfrn.org/~shu/drafts/ti.pdf‎ http://rfrn.org/~shu/drafts/ti.pdf‎ This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics). Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton: https://github.com/pcwalton/doctorjsmm/ https://github.com/pcwalton/doctorjsmm/ Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing. Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier. http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39? /be