10 ms·

I applaud every effort to improve Javascript as it all takes eons to download over my dialup but commonly does not actually work. A favorite contribution is ca

I applaud every effort to improve Javascript as it all takes eons to download over my dialup but commonly does not actually work. A favorite contribution is called something like "You Don't Really Need jQuery". I will dig it up,in a little bit. Of most serious concern is how to convince the working JS coder to actually avail themselves of better javascript? Most dont read HN. I find it is of no use to point out the errors of their ways.

CHY872 11y ago
This isn't for that. This work is to create a formal model of Javascript - a definition of what a perfect Javascript runtime should do. The next step (potentially) is then that you can reason about Javascript programs in a useful manner - you could prove that your security-critical script does the right thing, for example. Generally, such work does not lead to many updates to the state of the art - but is useful in its own way.
- MichaelCrawford 11y ago
  "I'm not really bad; I'm just drawn that way." -- Jessica Rabbit I see your point, but my concern that the coder who implements a security-critical script doesn't know he should use tools like this one. Lots of those who use other languages like to gripe about the many faults of PHP. While I agree that PHP has its problems I've used lots of languages that were far, far worse. My take is not that PHP is a bad language but that those who use it are often bad programmers. Take Bill at http://www.radioparadise.com/ http://www.radioparadise.com/ He at first built the sight with phpNuke, but rewrote it from scratch in the best of just a few days after "some boys from Brazil" overran it. Radio Paradise is still built on PHP, the difference is that Bill is an excellent engineer.
  - CHY872 11y ago
    They shouldn't use tools like this one, though. This is purely a research project and not industrially usable. In any case, the purpose is to specify what Javascript is supposed to do, and not what Javascript engines actually do. The interpreter was as easily as not an afternoon project; they probably got one for free. There's been some interesting discussion about this for the C language - useful yet undefined behaviours that are relied upon by many pieces of software, where a formal semantics such as this project may fall flat and lead to being overly restrictive. https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-discussion.html https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-...
    - MichaelCrawford 11y ago
      It would be a valuable contribution to publish the difference between what your tool says JS should do, and what production interpreters really do with that same JS source. I expect there is an open source test suite available. While at Apple in 1995 I came across a common in our system software that said "MacDraw needs this". Apple had a lending library with every third-party product that had ever been published, but for QA and bug isolation only. My job was mostly to isolate crashes that were stimulated by third party code. About half the time it was their fault; to the extent we possibly could we isolated it anyway by reverse-engineering their binaries. Apple Developer Tech Support would work with the developers to help them fix it. Sometimes its OK to depend on undocumented behavior, sometimes its not. Embedded systems for example might never receive new firmware so if the release firmware complies with specification then that undocumented behavior is completely cool.

CHY872 11y ago

This isn't for that. This work is to create a formal model of Javascript - a definition of what a perfect Javascript runtime should do. The next step (potentially) is then that you can reason about Javascript programs in a useful manner - you could prove that your security-critical script does the right thing, for example. Generally, such work does not lead to many updates to the state of the art - but is useful in its own way.

MichaelCrawford 11y ago
"I'm not really bad; I'm just drawn that way." -- Jessica Rabbit I see your point, but my concern that the coder who implements a security-critical script doesn't know he should use tools like this one. Lots of those who use other languages like to gripe about the many faults of PHP. While I agree that PHP has its problems I've used lots of languages that were far, far worse. My take is not that PHP is a bad language but that those who use it are often bad programmers. Take Bill at http://www.radioparadise.com/ http://www.radioparadise.com/ He at first built the sight with phpNuke, but rewrote it from scratch in the best of just a few days after "some boys from Brazil" overran it. Radio Paradise is still built on PHP, the difference is that Bill is an excellent engineer.
- CHY872 11y ago
  They shouldn't use tools like this one, though. This is purely a research project and not industrially usable. In any case, the purpose is to specify what Javascript is supposed to do, and not what Javascript engines actually do. The interpreter was as easily as not an afternoon project; they probably got one for free. There's been some interesting discussion about this for the C language - useful yet undefined behaviours that are relied upon by many pieces of software, where a formal semantics such as this project may fall flat and lead to being overly restrictive. https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-discussion.html https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-...
  - MichaelCrawford 11y ago
    It would be a valuable contribution to publish the difference between what your tool says JS should do, and what production interpreters really do with that same JS source. I expect there is an open source test suite available. While at Apple in 1995 I came across a common in our system software that said "MacDraw needs this". Apple had a lending library with every third-party product that had ever been published, but for QA and bug isolation only. My job was mostly to isolate crashes that were stimulated by third party code. About half the time it was their fault; to the extent we possibly could we isolated it anyway by reverse-engineering their binaries. Apple Developer Tech Support would work with the developers to help them fix it. Sometimes its OK to depend on undocumented behavior, sometimes its not. Embedded systems for example might never receive new firmware so if the release firmware complies with specification then that undocumented behavior is completely cool.