4 ms·

Douglas Crockford details a pile of problems with Javascript that have plagued it since the year zero. Dart needs to fix all these issues. Moreover Google reall

by wbhart 15y ago

Douglas Crockford details a pile of problems with Javascript that have plagued it since the year zero. Dart needs to fix all these issues. Moreover Google really pitched it as a better language than Javascript. So far the Dart implementors don't even implement their spec correctly and some of the completely broken things in Javascript have been retained. And some new ones have been added too. I'm absolutely stupified that their spec claims integers are not limited to 32 or 64 bits but only limited by the size of memory on the machine. Not only is that not true (they've just used the completely broken Javascript double precision floats), but it isn't even sensible. You cannot make bignums anywhere near as efficient as machine words. They've even thrown away some of the really brilliant things in Javascript. It's a total disaster. The spec is full of typos too. This is not a hackish attempt of some inexperienced computer science graduate student, it is a language developed by one of the richest corporations on earth. Regarding the fact that Dart has Null pointers, someone on Reddit commented "what were they smoking". Someone commented on HN that Google does not hire programming language theory experts. I wish I could vote that up a hundred times.

Peaker 15y ago
You can make bignums pretty close to the efficiency of machine words -- when storing values that fit in machine words. You do that by simply using tagged machine words. A few extra instructions protecting the bignum's use do not have a significant cost. In http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... Tim Sweeney says: Factoid: C# exposes more than 10 integer-like data types, none of which are those defined by (Pythagoras, 500BC). In the future, can we get integers right Neat Trick: In a machine word (size 2^n), encode an integer ±2^(n-1) or a pointer to a variable-precision integer § Thus “small” integers carry no storage cost § Additional access cost is ~5 CPU instructions But: § A natural number bounded so as to index into an active array is guaranteed to fit within the machine word size (the array is the proof of this!) and thus requires no special encoding. § Since ~80% of integers can dependently-typed to access into an array, the amortized cost is ~1 CPU instruction per integer operation. This could be a viable tradeoff.
- wbhart 15y ago
  In fact I've implemented precisely that first tradeoff in a library and it isn't too bad. It's still much slower than machine words though. In Dart this becomes more constrained as it uses dynamic typing. Apparently the types specified by the programmer will be thrown away when it is compiled down to VM instructions. They are only used to specify/check interfaces. What this means is that those tags become quite large in the implementation. You can try any Common Lisp or Scheme R6RS without type inference to see how fast or slow this is in practice. I don't completely understand the second trick. Where are the bignums?
  - Peaker 15y ago
    He's basically saying: If the integer is tagged in its static type to be within the range of some array -- then that is proof that it is not a "bignum" and can be stored as a machine word.
    - wbhart 15y ago
      Oh yeah. That's an optimisation more languages should use. But he clearly doesn't do much mathematics if he thinks most integers are array indices. His point is doubtlessly right in his problem domain though and maybe even for a large sector of the programming community.

by wbhart 15y ago

Peaker 15y ago

You can make bignums pretty close to the efficiency of machine words -- when storing values that fit in machine words. You do that by simply using tagged machine words. A few extra instructions protecting the bignum's use do not have a significant cost. In http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... Tim Sweeney says: Factoid: C# exposes more than 10 integer-like data types, none of which are those defined by (Pythagoras, 500BC). In the future, can we get integers right Neat Trick: In a machine word (size 2^n), encode an integer ±2^(n-1) or a pointer to a variable-precision integer § Thus “small” integers carry no storage cost § Additional access cost is ~5 CPU instructions But: § A natural number bounded so as to index into an active array is guaranteed to fit within the machine word size (the array is the proof of this!) and thus requires no special encoding. § Since ~80% of integers can dependently-typed to access into an array, the amortized cost is ~1 CPU instruction per integer operation. This could be a viable tradeoff.

wbhart 15y ago
In fact I've implemented precisely that first tradeoff in a library and it isn't too bad. It's still much slower than machine words though. In Dart this becomes more constrained as it uses dynamic typing. Apparently the types specified by the programmer will be thrown away when it is compiled down to VM instructions. They are only used to specify/check interfaces. What this means is that those tags become quite large in the implementation. You can try any Common Lisp or Scheme R6RS without type inference to see how fast or slow this is in practice. I don't completely understand the second trick. Where are the bignums?
- Peaker 15y ago
  He's basically saying: If the integer is tagged in its static type to be within the range of some array -- then that is proof that it is not a "bignum" and can be stored as a machine word.
  - wbhart 15y ago
    Oh yeah. That's an optimisation more languages should use. But he clearly doesn't do much mathematics if he thinks most integers are array indices. His point is doubtlessly right in his problem domain though and maybe even for a large sector of the programming community.