4 ms·
It's pretty cool to see all the different ways ECMA-262 has been implemented. I've been working on my own implementation[1] and seeing how other implementations
by snek 8y ago
It's pretty cool to see all the different ways ECMA-262 has been implemented. I've been working on my own implementation[1] and seeing how other implementations like v8, prepack, mongoosejs, and now this one solve things has been super helpful.
1: https://github.com/devsnek/engine262 https://github.com/devsnek/engine262
- mncharity 8y ago> pretty cool to see all the different ways ECMA-262 has been implemented My favorite is that the language spec was written as quite regular pseudo-code... so at least as of some years ago, and after some manual massage to clean up irregularities, one could automagically transliterate the text of the spec into code. And if the target language had label gotos (because the spec was full of 'then go to step N'), and permited arbitrary identifiers, then the code could read just like the spec. Making code-review proof reading much easier. That's one of my canaries for detecting when a non-crippling programming language finally exists - someone generates a not-necessarily performant but fully spec-compliant js implementation with some strikingly tiny effort. A few days.
- mras0 8y agoGood luck with your project, for now you should trust the other implementations more :) But I've tried to keep the code reasonably small and (hopefully) readable - which is why it's currently targeting ES1997 - rather than having lots of features, so it's probably more understandable than V8.