This is a great story. I’m not surprised that the first edition of the ECMAScript specification was so friendly to implementors. My understanding of the birth of JavaScript is that it was put together fairly quickly by Brendan Eich (the W3C’s page says in 10 days), and in fact that a number of the decisions were made based on what option was easiest to implement correctly in a short time frame.
Great story. The one thing I take issue with is his “I know better” approach, particularly when his choice to rewrite the parser is questionable. He says:
Now, if there was one thing that I had been taught in my computer science degree, it was how to quickly implement a programming language. You take two very powerful tools… (lex and yacc)
He uses this as a justification to dump the original parser and start from scratch. The problem with this that is nearly every popular language implementation today uses hand-written recursive descent parsers, just like the original author did. The reason they avoid lex and yacc is that these tools have serious limitations in error handling and parsing edge cases.
So maybe he should have been just making the original parser emit bytecode to improve execution speed rather than rewriting the whole parser from scratch in a different technology as well?
Having written way too many parsers in way too many formalisms, I can say that I feel it was a reasonable decision with the information presented. To someone who is already up to speed on how to debug LALR generators, it’s a lot faster to implement than the recursive descent approach, and the performance is known to be quite good.
One of the drawbacks is that it’s harder to hand-optimize for integrated parsing and lexing, but that possible benefit to a hand-parser would require far more than two weeks of profiling and experimenting. There is definitely a difference between a hand-parser that’s been tuned and refactored repeatedly by twenty competent engineers, and one that was written messily and hastily by a single person whose job title shields them from criticism of their code.
Also, in the 90s when this happened, lex and yacc were the accepted wisdom. Doing it by hand wasn’t taken seriously. That doesn’t affect how good or bad the decision was, but is a factor in the psychology of this story. :)
Edit: And he finished it by the deadline, so his time estimate must have been accurate. Estimating it accurately is way more impressive than meeting the deadline! :)
it was a hand-coded recursive descent parser (fair enough, but not the easiest thing to maintain, because the syntax and the parser logic were not separated, and because it was very long-winded);
with lexical analysis inlined in the parser (not a complete disaster, but it led to lots of duplicated code);
with lexical analysis using string matching rather than finite state machines (this was inefficient because attempted matches could fail many times before a token was finally accepted);
with evaluation interleaved with the parsing (very dodgy: it meant that programs would start running even if there were syntax errors later in the code);
and no data structure representing the parsed code (disaster!).
At that point, it makes all the sense in the world to remove the original parser–it’s not a matter of “let’s just add a bytecode interpreter to the original thing”.
Sometimes, there really isn’t anything worth saving. :(
This is a great story. I’m not surprised that the first edition of the ECMAScript specification was so friendly to implementors. My understanding of the birth of JavaScript is that it was put together fairly quickly by Brendan Eich (the W3C’s page says in 10 days), and in fact that a number of the decisions were made based on what option was easiest to implement correctly in a short time frame.
Some of the things (like function-scoping) seem to make a great deal of sense if you evaluate them in “How would I hack this together?”.
Great story. The one thing I take issue with is his “I know better” approach, particularly when his choice to rewrite the parser is questionable. He says:
He uses this as a justification to dump the original parser and start from scratch. The problem with this that is nearly every popular language implementation today uses hand-written recursive descent parsers, just like the original author did. The reason they avoid lex and yacc is that these tools have serious limitations in error handling and parsing edge cases.
So maybe he should have been just making the original parser emit bytecode to improve execution speed rather than rewriting the whole parser from scratch in a different technology as well?
Having written way too many parsers in way too many formalisms, I can say that I feel it was a reasonable decision with the information presented. To someone who is already up to speed on how to debug LALR generators, it’s a lot faster to implement than the recursive descent approach, and the performance is known to be quite good.
One of the drawbacks is that it’s harder to hand-optimize for integrated parsing and lexing, but that possible benefit to a hand-parser would require far more than two weeks of profiling and experimenting. There is definitely a difference between a hand-parser that’s been tuned and refactored repeatedly by twenty competent engineers, and one that was written messily and hastily by a single person whose job title shields them from criticism of their code.
Also, in the 90s when this happened, lex and yacc were the accepted wisdom. Doing it by hand wasn’t taken seriously. That doesn’t affect how good or bad the decision was, but is a factor in the psychology of this story. :)
Edit: And he finished it by the deadline, so his time estimate must have been accurate. Estimating it accurately is way more impressive than meeting the deadline! :)
Recall the problems he ran into:
At that point, it makes all the sense in the world to remove the original parser–it’s not a matter of “let’s just add a bytecode interpreter to the original thing”.
Sometimes, there really isn’t anything worth saving. :(