4 ms·
This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
by spankalee 13y ago
This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
- kevingadd 13y agoUsing a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior. This could have been accounted for with a better language design, but it wasn't.
- BrendanEich 13y agoCould have been accounted for in language design, dart2js effort, bignums-for-JS effort, or some combination of the last two. I don't want to assume a conclusion, but the lack of a fix for http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533 is a problem, even if there's no immediate fix. It is fixable. /be
- BrendanEich 13y agoNo, you changed the argument from correctness to performance. Makes me wonder if the problem is not entitled sloth with a dash of anti-JS animus, rather: wholesale, '90s-Microsoft-style-lock-in, submarine-the-other-browsers dirty pool. Of course, if dart2js produced too-slow-JS, that might limit Dart adoption. Not a dilemma, given a good-faith effort to optimize per my comment above -- and much better than forking the language between DartVM and dart2js, leaving a trap for the unwary Dart programmer to fall into when using dart2js to run on all the non-DartVM browsers. "Make it correct, then make it fast." Is this no longer done where you work? (Which would be Google, amirite? :-P) /be